个人网站api接口编写（编写API）

本篇文章给大家谈谈个人网站api接口编写，以及编写API对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享个人网站api接口编写的知识，其中也会对编写API进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、如何做一个淘宝api的程序，如果我是一个个人，没有企业资质，按照淘宝
• 2、个人网站能否申请淘宝Api接口？
• 3、个人支付宝api接口步骤
• 4、RESTful API 设计约定
• 5、如何设计好的RESTful API
• 6、如何使用zoundy写离线博客发布到google blogger？blogger的api接口是什么？

如何做一个淘宝api的程序，如果我是一个个人，没有企业资质，按照淘宝

可以的 架构就用"thinkphp" 开发语言用php php体系内会用到html5 、css 、JavaScript
如果还要加用"响应式"效果"Bootstrap"方便手机"jQuery"数据库"mysql"如果要处理图片还要学到"Photoshop" 了解这些 就可以做这种模板了 api接口需要自己在淘宝联盟平台接的

个人网站能否申请淘宝Api接口？

不存在淘宝助理api接口。淘宝助理，也并不是只调用了一个接口，而是很多个接口。
进入“淘宝开放平台”，点击api文档，搜索“商品api”和“店铺api”，你想调用的大部分数据都在这两个下面。还是找专业的人去做吧，你所要做的只是提出要求。

个人支付宝api接口步骤

个人支付宝api接口我们应该怎么弄呢，今天我们就来说说。

工具/材料

电脑

01

首先我们要找到的一定是支付宝官网，不然你的隐秘信息可能会泄露。然后登录或者注册支付宝账号。

02

在管理中心页面选择应用管理，是个人申请就选择第一个，不是就选择第二个。然后填写信息。

03

在信息填写好了之后就等待平台的审核就可以了。

RESTful API 设计约定

本文编写目个人网站api接口编写的是为了尽可能的约定好一个公司的产品、组件、项目开发的RESTful API 设计风格个人网站api接口编写，使不同团队间设计的API风格尽量一致，减少项目后期由于规范问题或设计不足导致的接口重构造成的开发、测试返工。最终让接口的最终使用者能够在开发过程中有个良好的体验。

此约定可作为开发人员设计RESTful 接口或项目接口发布评审的参考。

个人观点：用了 JSON-RPC 不等于 是RESTful API ，RESTful API通常是基于HTTP/JSON方式实现的 ，两种方式的API设计方式都不错，项目中选适合的就好。简单对比如下：

本文仅是作者个人根据主观喜好和接口设计经验搜罗总结而来的RESTful API设计约定，仅作为接口设计的基本要求，也欢迎与大家讨论。此约定未涉及超文本HATEOAS相关内容，也不包含RPC类面向后端服务方法映射接口的范畴。

API 是后端应用程序的脸面(UI)，用户体验非常重要。尤其是当你开发的是一个可复用的组件或产品，如果API设计有些许瑕疵，会直接影响开发者的体验，设计者会被骂的…… 有问题的API一旦开放出去了，哪怕是简单的拼写错误，由于要保持兼容性不能删改，会成为技术欠债长期背下去。

以上关键点不只适用于RESTful API，其个人网站api接口编写他类型API也是一样的。

作为对外公开发布的RESTful API，根URL中一般要有域名与版本信息。通常一个WEB站点会同时提供网站服务和API服务，个人网站api接口编写我们需要根据URL能够区分出访问的是服务接口还是网站中的网页、文件等资源。因此RESTful API的根URL中根据不同场景一般会在一级域名中或者是子域名中带api关键字。

常见的两种根URL用法如下：

推荐的方案是根URL中采用子域名的方式区分API，即： https://iam.primeton.com/api/v1/*

路径终点即粗体部分内容： https:// example.org/api/v1/ menus

设计RESTful API时常用的HTTP Method包括：GET、POST、PUT、PATCH、DELETE 简单说明如下：

根据资源标识可以 唯一定位一个资源 时，建议使用URL路径参数方式传递。对应Springboot 的 @PathVariable 。API Path示例如下：

根据资源属性查询过滤 一或多个资源 时，建议使用URL查询参数方式传递。对应Springboot的 @RequestParam 。API Path示例如下：

对于简单查询类接口，可以使用路径参数和查询参数解决，如果是复杂功能型查询接口中需要通过复杂的过滤条件查询时如： < in between 等等，查询参数用起来会非常痛苦，GET Method又不支持提交Request Body参数。因此个人网站api接口编写我建议这种 复杂型查询采用POST Method 提交到一个特定的Path上 。参见如下场景：

查询接口返回多个数据时，需要支持分页（枚举类数据或少量数据除外）和排序。

如需使用分页查询和排序，建议统一请求与响应报文结构，格式如下：

请求参数示例：

GET /users?page=1size=5sort=username

单页数据响应结果示例：

上述分页排序与响应报文格式是来自Spring Data定义的模型，为了保持分页排序接口相关的使用习惯，如果持久化不使用JPA，仍然建议采用上述规范的报文定义封装接口。为使用者提供一致的体验。

如果资源需要做一些增删改之外的操作（如状态变更），可以用 /actions 作为path

例如：流程平台中的流程实例会有状态变化，如启动、挂起、恢复、终止等等，这种接口建议这样设计：

组合资源，即两种资源之间存在组合关系，组合指整体与部分的强包含关系，但整体与部分是不可分的，整体的生命周期结束也就意味着部分的生命周期结束。对"部分"的操作一定会由整体作为入口，不会直接跳过"整体"来对"部分"做增删改查。这种组合场景中，推荐API设计方式示例如下：

聚合资源，即两种资源之间存在聚合关系。聚合也是整体与部分的弱包含关系，但整体与部分之间是可分离的，他们可以具有各自的生命周期，部分可以属于多个不同的主体对象，也可以为多个整体对象共享。

例如，机构或角色下包含人员，需要获取机构或角色下的人员的场景，避免做成分别通过机构入口或角色入口找人等重复的具有类似功能的接口：

在RESTful API设计中，正常和异常情况建议通过HTTP约定的status进行区分， 不建议 采用所有接口均POST Method调用，永远返回200这种模式。

推荐的常用Http Status说明如下：

HTTP 1.0 Status 详细说明参考

API调用成功后，返回HTTP 2xx状态码，Response Body直接返回业务数据即可。请求和响应报文建议统一采用JSON格式。

RESTful API 对于异常报文需要规范和统一，服务端出现异常情况下，需要进行全局拦截，然后将异常信息封装为规范的格式，返回给调用端。

对于后端的异常信息，建议包含编码和消息

本文是基于学习各路大神们对RESTful 设计相关文章，结合自己设计接口时遇到困惑后的解决方案，收集与总结而成的RESTful API设计约定。部分内容夹杂个人喜好与主观观点，抛砖引玉，希望能为大家设计API带来些许帮助。后如果遇到一些更复杂的场景，欢迎一起沟通。

如何设计好的RESTful API

安全是恒久的话题，对于基于WSDL和SOAP的Web Service，我们有WS-Security这样的安全规范来指导实现认证、授权、身份管理等安全需求。那么，RESTful API有无成熟可用规范或实现框架呢？如何保证RESTful API的安全性呢？
如何对RESTful API进行版本控制，请分享您认为实用的做法？
HTTP1.1规范中给出的动词对于设计RESTful API够用吗？您在实际项目中会扩展自己的动词吗？在什么情况下需要扩展？
今年5月份发布的JAX-RS 2.0规范对于RSTfulAPI的设计最有价值的特性是哪个（些）? 它（们）用于解决什么问题？
能否为InfoQ的读者们推荐一款实用的RESTful API开发框架，并说明您的推介理由。
HTTP2.0规范正在制定当中，您对它的期待是什么？
InfoQ：什么是好的RESTful API？相信每个人都有自己的评判标准。那么，您认为一个好的RESTful API应该具有哪些特征呢？

李锟：一个好的RESTful API，应该具备以下特征：
这个API应该是对浏览器友好的，能够很好地融入Web，而不是与Web格格不入。
浏览器是最常见和最通用的REST客户端。好的RESTful API应该能够使用浏览器+HTML完成所有的测试（不需要使用编程语言）。这样的API还可以很方便地使用各种自动化的Web功能测试、性能测试工具来做测试。Web前端应用（基于浏览器的RIA应用、移动App等等）也可以很方便地将多个RESTful API的功能组合起来，建造Mashup类的应用。
这个API中所包含的资源和对于资源的操作，应该是直观和容易理解的，并且符合HTTP协议的要求。
REST开发又被称作“面向资源的开发”，这说明对于资源的抽象，是设计RESTful API的核心内容。RESTful API建模的过程与面向对象建模类似，是以名词为核心的。这些名词就是资源，任何可命名的抽象概念都可以定义为一个资源。而HTTP协议并不是一种传输协议，它实际提供个人网站api接口编写了一个操作资源的统一接口。对于资源的任何操作，都应该映射到HTTP的几个有限的方法（常用的有GET/POST/PUT/DELETE四个方法，还有不常用的PATCH/HEAD/OPTIONS方法）上面。所以RESTful API建模的过程，可以看作是具有统一接口约束的面向对象建模过程。
按照HTTP协议的规定，GET方法是安全且幂等的，POST方法是既不安全也不幂等的（可以用来作为所有写操作的通配方法），PUT、DELETE方法都是不安全但幂等的。将对资源的操作合理映射到这四个方法上面，既不过度使用某个方法（例如过度使用GET方法或POST方法），也不添加过多的操作以至于HTTP的四个方法不够用。
如果发现资源上的操作过多，以至于HTTP的方法不够用，应该考虑设计出更多的资源。设计出更多资源（以及相应的URI）对于RESTful API来说并没有什么害处。
这个API应该是松耦合的。
RESTful API的设计包括了三个循序渐进、由低到高的层次：资源抽象、统一接口、超文本驱动。正是这三个层次确保了RESTful API的松耦合性。
当设计面向互联网的API时，松耦合变成了一种“必须有”的强需求。紧耦合的API非常脆弱，一旦公布出去，服务器端和客户端都无法持续进化。尤其是服务器端，公布出去的接口根本不敢改，改了之后，几乎所有客户端应用立即无法正常工作。REST这种架构风格就是紧耦合API的解毒剂，这个话题可以谈的很深，这里就不展开了。感兴趣的读者可以参考《REST实战》。
这个API中所使用的表述格式应该是常见的通用格式
在RESTful API中，对于资源的操作，是通过在服务器端-客户端之间传递资源的表述来间接完成的。资源的表述可以有很多种格式，并且在响应和请求中的资源表述格式也会有所不同。GET/POST响应中的资源表述格式，常见的有HTML、XML、JSON个人网站api接口编写；POST/PUT请求中的资源表述格式，常见的有标准的HTML表单参数、XML、JSON。
这些常见表述格式，处理起来非常容易，有大量的框架和库提供支持。所以除非有很合理的要求，通常不需要使用自定义的私有格式。
使用HTTP响应状态代码来表达各种出错情况
HTTP响应状态代码，是HTTP协议这个统一接口中用来表达出错情况的标准机制。响应状态代码分成两部分：status code和reason phase。两部分都是可定制的，也可以使用标准的status code，只定制reason phase。
如果一个所谓的“RESTful API”对于任何请求都返回200 OK响应，在响应的消息体中返回出错情况信息，这种做法显然不符合“确保操作语义的可见性”这个REST架构风格的基本要求。
这个API应该对于HTTP缓存是友好的
充分利用好HTTP缓存是RESTful API可伸缩性的根本。HTTP协议是一个分层的架构，从两端的user agent到origin server之间，可以插入很多中间组件。而在整个HTTP通信链条的很多位置，都可以设置缓存。HTTP协议内建有很好的缓存机制，可以分成过期模型和验证模型两套缓存机制。如果API设计者完全没有考虑过如何利用HTTP缓存，那么这个API的可伸缩性会有很多问题。
李建业：首先说明一下，对REST这个概念，我一般把它理解为REST风格的架构，但是现在实践中最为广泛认知的是HTTP，而它是REST的一个实现，所以RESTful API也可以不太严格的指基于HTTP的API——当然，即使是不严格的时候，API本身也应该力求遵循REST架构风格。
我认为，一个RESTful API最重要的一点应该是——“尽可能少的先验信息”，这一条也同时是我判断一个好的RESTful API的标准。
比如HTTP动词，在实践中，大家可能会常常纠结于有效利用 HTTP 动词，但这却并不是特别重要的事情——除非你理解这么做的价值。HTTP 动词最重要的地方在于它是标准阐明了的行为，也就是说，如果我们的“客户端”遵循约定，那么就不必要发明新的动词，也就不必增加“先验信息”；但是，所谓“先验信息”，针对的是客户端——对API来说就是调用者，对于一些企业内部系统，或者一些传统系统，由于“资源”很稳定，对资源的操作也很稳定，这些系统的“调用客户端”不是浏览器而是另一个系统，此时如果强制对应到HTTP动词，反而会变成额外的“先验信息”，这时我就不会太拘泥HTTP动词，自己制定一套动词放在参数中也可以接受——只要动词不变化，这个系统依然是REST风格的。
再比如Response里面的Content-Type，这个有时会被新手忽略，但这其实很重要，因为一般涉及到系统间协同的API，往往不会使用普通的文本，比较常见的是使用json表达复杂结构，而这与通常的缺省理解不同（缺省一般会认为是text/plain和text/html），所以如果在API中忘记用Content-Type进行区分的话，后续对多种类型的客户端接入的支持就会变成陷阱（我们多次遇到过这个问题）。而如果一开始就检查是否增加先验知识（缺省Content-Type为plain或者允许指定Content-Type），那这一困难就可以避免了。
丁雪丰：首先，应该正确地使用HTTP的统一接口，比如HTTP的动词，如果不分青红皂白清一色POST那显然还有改进的余地；
其次，资源有合适的粒度，可以从三个方面来评判资源的粒度是否合理——网络的效率、表述的大小以及客户端使用时的易用程度；
最后，是表述的设计，除了表述的正文内容，还有其中的URI和链接，这些都是评判一个RESTful API好坏的标准。
马钧：在我看来，一个好的API标准，就是能尽量利用到HTTP协议的特性，将HTTP当成一种转移协议，而不是传输协议。包括但不限于：利用HTTP的各种动词来明确操作；包含有内容协商，可以根据请求头提供的参数选择一个资源最合适的媒体类型、语言、字符集和编码的表现；使用不同的返回代码来描述各种状态。但实际上见到过的很多声称RESTful API，包括国内的和国外的，能符合这些条件的并不多。parse.com提供的API是我见到过的较为不错的RESTful API，可以作为范例参考。
InfoQ：安全是恒久的话题，对于基于WSDL和SOAP的Web Service，我们有WS-Security这样的安全规范来指导实现认证、授权、身份管理等安全需求。那么，RESTful API有无成熟可用规范或实现框架呢？如何保证RESTful API的安全性呢？
李锟：保证RESTful API的安全性，主要包括三大方面：
a) 对客户端做身份认证
b) 对敏感的数据做加密，并且防止篡改
c) 身份认证之后的授权
对客户端做身份认证，有几种常见的做法：
在请求中加签名参数
为每个接入方分配一个密钥，并且规定一种签名的计算方法。要求接入方的请求中必须加上签名参数。这个做法是最简单的，但是需要确保接入方密钥的安全保存，另外还要注意防范replay攻击。其优点是容易理解与实现，缺点是需要承担安全保存密钥和定期更新密钥的负担，而且不够灵活，更新密钥和升级签名算法很困难。
使用标准的HTTP身份认证机制
HTTP Basic身份认证安全性较低，必须与HTTPS配合使用。HTTP Digest身份认证可以单独使用，具备中等程度的安全性。
HTTP Digest身份认证机制还支持插入用户自定义的加密算法，这样可以进一步提高API的安全性。不过插入自定义加密算法在面向互联网的API中用的不是很多。
这个做法需要确保接入方“安全域-用户名-密码”三元组信息的安全保存，另外还要注意防范replay攻击。
优点：基于标准，得到了广泛的支持（大量HTTP服务器端、客户端库）。在服务器端做HTTP身份认证的职责可以由Web Server（例如Nginx）、App Server（例如Tomcat）、安全框架（例如Spring Security）来承担，对应用开发者来说是透明的。HTTP身份认证机制（RFC 2617）非常好地体现了“分离关注点”的设计原则，而且保持了操作语义的可见性。
缺点：这类基于简单用户名+密码机制的安全性不可能高于基于非对称密钥的机制（例如数字证书）。
使用OAuth协议做身份认证
OAuth协议适用于为外部应用授权访问本站资源的情况。其中的加密机制与HTTP Digest身份认证相比，安全性更高。需要注意，OAuth身份认证与HTTP Digest身份认证之间并不是相互取代的关系，它们的适用场景是不同的。OAuth协议更适合于为面向最终用户维度的API提供授权，例如获取隶属于用户的微博信息等等。如果API并不是面向最终用户维度的，例如像七牛云存储这样的存储服务，这并非是OAuth协议的典型适用场景。
对敏感的数据做加密，并且防止篡改，常见的做法有：
部署SSL基础设施（即HTTPS），敏感数据的传输全部基于SSL。
仅对部分敏感数据做加密（例如预付费卡的卡号+密码），并加入某种随机数作为加密盐，以防范数据被篡改。
身份认证之后的授权，主要是由应用来控制。通常应该实现某种基于角色+用户组的授权机制，这方面的框架有不少（例如Spring Security），不过大多数开发团队还是喜欢自己来实现相关功能。
李建业：我不认为安全是RESTful API需要考虑的问题，事实上我觉得这是两个正交的问题。当然，如果使用RESTful API来提供认证、授权和身份管理，那也算是双方有关系，但是这和其它风格的API设计所要考虑的问题似乎没什么区别，不值得特别注意。
但是在具体设计层面，这两者的“正交点”上似乎确实有些问题，因为REST是一个推崇状态无关原则的架构风格，而认证和授权通常基于第三方解决方案，所以往往会出现违背有状态约束的问题，这个地方我也没有特别的想法，当然这个困难和原问题关系不大。
至于WS-族的协议，我不太了解，不太能参与讨论。
丁雪丰：对于RESTful API，常见的安全措施都是可以继续使用的。例如，为了防篡改，可以对全部参数进行签名；为了防范重放攻击可以在请求中增加一次性的Token，或者短时间内有效的Token；对内容加密可以实现数据防泄露……；对于DDoS攻击，各种HTTP流量清洗策略，都可以继续发挥作用，因为这就是基本的HTTP请求。
在授权和认证方面，OAuth 2.0已经基本成熟了，并且得到了广泛地应用。如果可以，接入第三方账户体系是个不错的选择，比如Google和Facebook的，国内的当然也有几个候选。
马钧：个人认为RESTful的安全性分为几个层次，在安全要求较高的场合，可以通过HTTPs这样的加密协议来保证网络层的安全，应用层的安全可以通过OAuth实现认证，而对于资源的访问授权，则只能依靠应用程序来实现了。
InfoQ：如何对RESTful API进行版本控制，请分享您认为实用的做法？
李锟：一个比较简单实用的做法是直接在URI中插入版本号，这样做允许多个版本的API并行运行。
另一个做法是在HTTP请求中加入自定义头信息，标明使用的版本号。不过这个做法其实对浏览器不够友好，简单地使用浏览器+HTML无法测试。
李建业：目前比较好的方式还是在uri设计中添加版本信息，其它方法都不如这个实用。
丁雪丰：个人认为最好的版本化，就是没有明显的版本。在对已发布的服务进行变更时，要尽量做到兼容，其中包括URI、链接和各种不同的表述的兼容，最关键的就是在扩展时不能破坏现有的客户端。例如，要变更一个参数，可以选择同时兼容新旧两种输入，或者保持老参数不动，提供一个新的参数，在文档中必须做出说明，不推荐新用户再继续使用之前的参数。
如果必须要进行不兼容的变更，那么可以选择标记不同的版本号，这时可以选择在路径或参数中增加版本信息。也有做法是增加HTTP标头，只是在调用时会稍有不便，推荐前两种方法。
马钧：RESTfulAPI的版本升级，尽量兼容之前的版本，保证原有的API都能正常工作，可以通过HTTP 301转跳到新的资源。另外一种实用的做法就是在url中保留版本号，同时提供多个版本供客户端使用，如 v1.rest.com 或者 rest.com/v1/ 这样。
InfoQ：HTTP1.1规范中给出的动词对于设计RESTful API够用吗？您在实际项目中会扩展自己的动词吗？在什么情况下需要扩展？
李锟：这个问题取决于设计者如何看待和设计资源。如果资源抽象做的很好，对于某个资源的任何操作，通常都能够映射到CRUD四个类别中。CRUD四个类别对于操作资源来说，绝大多数情况下是完备的。HTTP的GET/POST/PUT/DELETE四个方法，对于CRUD四个类别的操作来说是足够的，映射关系是Create-POST/Retrieve-GET/Update-PUT/Delete-DELETE。
我们通常不会选择创建自己的动词，这样做对于客户端开发者来说，需要更多的学习成本。如果在资源上定义的操作过多，我们会选择拆分出更多的资源。
李建业：一般是够用的，有时一些“不够用”的场景是由于我们没有设计出合理的资源，比如批量操作。但是，正如之前所说的那样，对于某些内部的、传统的（因此模型稳定且已知）系统，API提供者和调用者会有自已的固定动词表，此时没必要拘泥。另外，我不建议扩展动词，一旦扩展了动词，其实已经破坏了我之前说的*“尽可能少的先验信息”*，那么，扩展动词和重新设计动词的成本差别不大。基于这个考虑，我建议尽可能保持动词不变，除非你想重新设计动词表。
丁雪丰：一般情况下，常用的HTTP动词是够用的，并没有出现一定要自己扩展动词的情况。其实，最常用的也就是GET、POST、DELETE和PUT，而HEAD、OPTIONS、TRACE则基本用不太到。如果出现一时找不到合适的动词，安全幂等的操作用GET，其个人网站api接口编写他都可以用POST，在设计资源时稍加考虑即可。
马钧：在我的实际项目中，只用到了POST，PUT，DELETE，GET这四个动词。
InfoQ：今年5月份发布的JAX-RS 2.0规范对于RSTfulAPI的设计最有价值的特性是哪个（些）? 它（们）用于解决什么问题？
李锟：REST开发框架RESTEasy项目负责人Bill Burke，去年写了一篇文章介绍JAX-RS 2.0。
我同意Bill在文章中的观点，在JAX-RS 2.0增加的内容中，最重要的三部分为：
a) Client API——用来规范化JAX-RS客户端的开发方式。
b) Server-side Asynchronous HTTP——用来实现服务器端推送功能，而不需要依靠低效的轮询方式。
c) Filters and Interceptors——用来分离关注点，将鉴权、日志等逻辑与业务逻辑分离开，更好地实现代码重用。
这三部分的内容对于开发者来说都很有用。遵循JAX-RS规范做开发，可以确保服务器端以及客户端代码的可移植性。
李建业：我个人关注异步API这部分，主要是因为流式服务将会越来越多，那将大量需要这类支持。
InfoQ：能否为InfoQ的读者推荐一款实用的RESTful API开发框架，并说明您的推介理由。
李锟：这个问题我就不详细回答了。不同的编程语言有不同的REST开发框架，对于REST的支持程度也不同。开发RESTful API的需求范围很广，可选择的开发框架的范围也很广。保持多样性是繁荣生态环境的基础。像Java就有支持JAX-RS规范的Jersey、RESTEasy、Restlet、Apache CXF，和不支持JAX-RS规范的Spring MVC等等很多框架。这些框架目前都做的不错。我对框架的选择没有倾向性。RESTful API设计的最佳实践应该是通用的，而不是必须依赖某种特定的开发框架。
李建业：不好意思，这个我不太重视，没法推荐，不过我可以解释一下为什么对RESTful API框架不感冒的原因。
REST作为一个架构风格，对我们的系统开发有很大影响，但是这些影响一般是针对架构（例如状态无关）或者设计（例如资源识别）上的，所以一旦涉及到具体实现，主要工作就基本结束了，此时开发框架能做的事也就只有简化编程了（相较而言，有的框架还能起到引导设计的作用），而由于RESTful会抽象动词，所以实现层面中和API规范相关的工作本来就不多，那么框架的价值就更小了。
当然，我们也不可能直接基于servlet/rakc/wsgi来开发，不过一般的编程语言都会提供一些简单的url route/match策略，我们使用这些就足够了。另外，有些框架能帮我们生成全部的动词支持，但这也未必是好事，我一般倾向于按需实现——用到了再支持，这就更不需要太关注开发框架对RESTful的支持了。
丁雪丰：由于本人是Spring的拥护者，工作中也一直在使用Spring，所以在选择框架时会更多地倾向Spring MVC（并不是说别的框架不好，这里有些个人主观的成份）。如果一定要选择其个人网站api接口编写他框架，也要选择能够方便与Spring集成的框架。如果在项目中已经使用了Spring，那么没有什么理由不选择Spring MVC，鉴于目前Spring在各种项目中的高出镜率，相信一般情况下都会选择Spring MVC。
REST的成熟度模型中，第三层就是HATEOAS，Spring目前还提供了Spring Hateoas子项目，对链接、资源等方面的支持都做了一定的增强。
马钧：我目前在实际项目中使用的是Spray，这是一个开源的 REST/HTTP 工具包和底层网络 IO 包，基于 Scala 和 Akka 构建。轻量级、异步、非堵塞、基于 actor 模式、模块化和可测试是Spray的特点。
InfoQ：HTTP2.0规范正在制定当中，您对它的期待是什么？
李锟：我的期待包括两个方面：应该做的和不应该做的。
HTTP/2.0规范应该做的：
与HTTP/1.1协议保持兼容。兼容的含义是说两者可以并存，客户端应用可以根据服务器端的能力，自由地选择使用HTTP/2.0还是HTTP/1.1，而且选择过程对应用来说是透明的。
改进HTTP协议（作为资源的统一接口）之中操作语义表达方式的语法，提高网络传输效率。
更好地模块化，这样HTTP/2.0协议的实现能够更好地模块化。应用程序可根据需要选择适当的模块，而不是要么全有、要么全无。
废弃掉HTTP/1.1协议中一些很少有人用到的部分，例如采用管道（pipelining）方式发送请求。
增加更多的动词，以适应除CRUD之外的其他场景。
HTTP/2.0规范不应该做的：
HTTP/2.0协议不应该把底层的数据加密机制（即SSL）作为必选项。
HTTP/2.0协议不应该背离REST架构风格的约束，尤其是要确保操作语义对于中间组件的可见性。
在上面这两个方面，Roy Fileidng曾经与SPDY协议设计者Mike Belshe发生过激烈争论，详情请看：Roy Fielding谈Google SPDY协议
李建业：对此规范关注不多，不知道会不会有对于流的支持，目前我所知道的只有chunk方式进行简单的支持，但是真正的流需要区分数据通道和控制通道——哪怕是逻辑上的区分，这样就直接对REST风格产生了很大冲击，考虑到流式服务在未来的发展潜力，我特别期待业界在这方面有所进展。
丁雪丰：HTTP 2.0很大程度上是借鉴了Google的SPDY，就我而言，首先，希望这个规范能做到与HTTP 1.1的兼容，使用者如果只认识1.1，那么2.0能优雅“降级”；其次，希望2.0能带来更好的性能，SPDY在这方面还是有所改进的，希望HTTP 2.0能再接再厉；最后，希望这个规范能在最终定稿时附带一个最佳实践，正确引导人们合理地使用HTTP 2.0。
马钧：没研究过，估计即使出来，1.1还有很长的生命周期，不会很快被取代。

如何使用zoundy写离线博客发布到google blogger？blogger的api接口是什么？

1、 Blog（from wiki）
历史：
Blog一词本起源于 weblog，意思是网上日志。1997年由 Jorn Barger所提出。在1998年， infosift 的编辑Jesse J. Garrett (http://www.jjg.net)，将一些类似blog的网站收集起来，寄给Cameron Barrett。 Cameron随后将名单发布在CamWorld网站上，许多人亦陆续将blog的URL给Cameron，慢慢的，一个新的网络社区俨然成型。1999年，Brigitte Eaton (http://www.eatonweb.com)成立一个weblog 目录，收集她所知道的blog站。1999年，Peter Merholz (http://www.peterme.com)首次使用缩略词“blog”，成为今天常用的术语。但是，blog 真正开始快速发展的转折点，是在1999年6月，当时Pitas开始提供免费的weblog服务，紧接着8月，Pyra lab推出了现在的blogger.com。blogger.com 提供了简单易学的说明，以及能通过FTP直接将blog发表在个人网站上的功能，这带给使用者很大的方便。目前已经有了很多Blog托管服务商(BSP)，业内人士对其盈利前景，持谨慎乐观态度。
Blog的特点
Blog是个人或群体以时间顺序所作的一种记录，并且不断更新。blog之间的交流主要是通过回溯引用（TrackBack）和回响/留言/评论（comment）的方式来进行的。blog的操作管理用语，也借鉴了大量档案管理用语。一个blog亦可被视为一个档案（archives），或是卷宗（fonds）。与传统档案不同的是，blog的写作者（blogger），既是这份档案的创作人（creator），也是其档案管理人（archivist）。
Blog大量采用了RSS（Really Simple Syndication或者Rich Site Summary或者RDF Site Summary）技术，所有的RSS文件都必须符合由W3C发布的XML 1.0规范。对读者来说，可以通过RSS订阅一个blog，确知该blog作者最近的更新。对Blog作者来说，RSS可以使自己发布的文章易于被计算机程序理解并摘要。
对知识管理和创造而言，blog提供了新的形态和途径。对汉语为母语的人而言，blog写作既接续了汉语笔记文学的优秀传统，更充分鼓励了个人表达。从交往形态考察，网志空间（blogosphere）设定了积极的读者、作者、编者互动转换关系，“言者互重，阅者相惜 ”。
2、 Tag （from blogbus）
什么是Tag？
Tag（标签）是一种更为灵活、有趣的日志分类方式，您可以为每篇日志添加一个或多个Tag（标签），然后您可以看到BlogBus上所有和您使用了相同Tag的日志，并且由此和其他用户产生更多的联系和沟通。不仅如此，我们还通过与Technorati的合作，把您的Tag发送到全球Blog空间，和全世界的人们共同分享。
Tag体现了群体的力量，使得日志之间的相关性和用户之间的交互性大大增强，可以让您看到一个更加多样化的世界，一个关联度更大的Blog空间，一个热点实时播报的新闻台。Tag为您提供前所未有的网络新体验……
当然，您也可以简单地把一个Tag（标签）理解为一个日志分类，但是Tag和分类的不同之处也很明显：
首先，分类是您在写日志之前就定好的，而Tag是在您写完日志之后再添加的；
其次，您可以同时为一篇日志贴上好几个Tag（标签），方便自己随时查找，而原先一篇日志只能有一个分类；
再次，当您积累了一定数量的Tag之后，您可以看看自己在Blog中最经常写的是哪些话题；
最后，您可以看到有哪些人和自己使用了一样的Tag（标签），进而找到和您志趣相投的Blogger。
举一个例子，比如说：您写了一篇到西湖旅游的日志，原来您都是把这一类的日志放到自己的“驴行天下”分类下，但是有了Tag之后，您可以给这篇日志同时加上“旅游”、“杭州”、“西湖”、“驴行天下”等几个Tag，当浏览者点击其中任何一个Tag，他都可以看到您的这篇日志。同时您自己也可以通过点击这几个Tag，看看究竟有谁最近也去了杭州旅游，或许你们还可以交流一下旅游心得，成为下一次出游的伙伴呢！
3、 SNS
Social Network Service，社会性网络软件，依据六度理论，以认识朋友的朋友为基础，扩展自己的人脉。并且无限扩张自己的人脉，在需要的时候，可以随时获取一点，得到该人脉的帮助。
SNS网站，就是依据六度理论建立的网站，帮你运营朋友圈的朋友。
4、 RSS（from wiki）
RSS是一种用于共享新闻和其他Web内容的数据交换规范，起源于网景通讯公司的推"Push"技术，将订户订阅的内容传送给他们的通讯协同格式(Protocol)。RSS可以是以下三个解释的其中一个：
Really Simple Syndication（真正简单的整合）
RDF (Resource Description Framework) Site Summary
Rich Site Summary（丰富站点摘要）
但其实这三个解释都是指同一种Syndication的技术。
目前RSS规范的主要版本有0.91、1.0和2.0。
0.91版和1.0版完全不同，风格不同，制定标准的人也不同。0.91版和2.0版一脉相承。1.0版更靠拢XML标准。
RSS目前广泛用于blog、wiki和网上新闻频道，世界多数知名新闻社网站都提供RSS订阅支持。
5、 Wiki（from wiki）
Wiki一词源自夏威夷语的「wee kee wee kee」，本是「快点快点」之意。在这里Wiki指的是一种超文本系统。这种超文本系统系支持那些面向社群的协作式写作，同时也包括一组支持这种写作的辅助工具。有人认为，Wiki系统属於一种人类知识的网路系统，我们可以在Web的基础上对Wiki文本进行浏览、创建、更改，而且这种创建、更改、及发布的代价远比HTML文本小；与此同时Wiki系统还支持那些面向社群的协作式写作，为协作式写作提供了必要的帮助；最后，Wiki的写作者自然构成了一个社群，Wiki系统为这个社群提供了简单的交流工具。与其它超文本系统相比，Wiki有使用简便且开放的优点，所以Wiki系统可以帮助我们在一个社群内共用某个领域的知识。
Wiki起源
1995年沃德?坎宁安（Ward Cunningham）为了方便模式社群的交流创建了全世界第一个wiki系统－WikiWikiWeb，并用它建立了波特兰模式知识库（Portland Pattern Repository）。在建立这个系统的过程中，沃德?坎宁安创造了Wiki的概念和名称，并且实现了支持这些概念的服务系统。这个系统是最早的Wiki系统。从1996年至2000年间，波特兰模式知识库围绕著面向社群的协作式写作，不断发展出一些支持这种写作的辅助工具，从而使Wiki的概念不断得到丰富。同时Wiki的概念也得到了传播，出现了许多类似的网站和软体系统。
Wiki的历史不长，无论是Wiki概念本身，还是相关软体系统的特性，都还在热烈的讨论中；所以怎样的一个站点才能称得上是一个Wiki系统还是有争议的。与Wiki相关新近出现的技术还有blog，它们都降低了超文本写作和发布的难度。这两者都是同内容管理系统密切相关的。
Wiki的特点
使用方便
维护快捷：快速创建、存取、更改超文本页面（这也是为什麼叫作 "wiki wiki" 的原因）。
格式简单：用简单的格式标记来取代 HTML 的复杂格式标记。（类似所见即所得的风格）
链接方便：通过简单标记，直接以关键字名来建立链接（页面、外部连接、图像等）。
命名平易：关键字名就是页面名称，并且被置於一个单层、平直的名空间中。
可增长
可增长：页面的链接目标可以尚未存在，通过点击链接，我们可以创建这些页面，从而使系统得以增长。
修订历史：记录页面的修订历史，页面的各个版本都可以被获取。
开放性
开放的：社群内的成员可以任意创建、修改、或删除页面。
可观察：系统内页面的变动可以被来访者清楚观察得到。
由於Wiki的自组织，可增长以及可观察的特点，使Wiki本身也成为一个网路研究的对象。对Wiki的研究也许能够让人们对网路的认识更加深入
理论和技术：
1、 六度关系理论
目前流行的“六度分隔”理论是20世纪60年代由美国的心理学家米格兰姆（Stanley Milgram）提出的，这个理论可以通俗地阐述为： 最多通过六个人你就能够认识任何一个陌生人。“六度分隔”成为人际关系世界中无可否认而又令人震惊的特征，许多社会学上的深入研究也给出令人信服的证据，说明这一特征不只是特例，在一般情形下也存在。 最近，美国哥伦比亚大学社会学系的瓦茨教授领导的EMAIL试验也再次证明了这一人际关系世界中惊人的规律。然而，在现实世界中，六十亿人怎么可能真的构成如此紧密的相互关联呢？是互联网使一切成为现实。
2、 Xml
XML即可扩展标记语言（eXtensible Markup Language）。标记是指计算机所能理解的信息符号，通过此种标记，计算机之间可以处理包含各种信息的文章等。如何定义这些标记，既可以选择国际通用的标记语言，比如HTML，也可以使用象XML这样由相关人士自由决定的标记语言，这就是语言的可扩展性。XML是从SGML中简化修改出来的。它主要用到的有XML、XSL和XPath等。
3、 AJAX
Ajax并不是一种技术。它实际上是几种已经在各自领域大行其道技术的强强结合。Ajax混合了：
* 基于XHTML/CSS
* 由DOM（Document Object Model）实现动态显示与交互
* 通过XML和XSLT进行数据交换及处理
* 使用JavaScript整合上述技术
直观一点的说Ajax能够实现不刷新浏览器窗口（当然更不用安装额外的插件）而满足用户的操作，现在一些看上去很Cool的网站，很多是用这项技术实现的，其中包括：orkut、Gmail、Google Group、Google Suggest、Google Maps、Flickr、A9.com等。2SIMPLE的Co-mment系统虽然没有用到XML/XSLT，其理念已经暗合容Ajax，实现了不刷新网页提供动态内给用户。
现有的产品：
Wiki百科、Wallop 、yahoo360 、openbc 、 cyworld 、43things 、 flickr、 del.icio.us、 cragslist 、glob 、客齐集、 friendster 、 linkin 、UU通 、 优友 、 天际网 、爱米网 、linkist 、新浪点点通、skype、亿友、cyworld
现在说说web2.0的具体应用。
历史很重要。对一个技术的学习也应当从历史出发，通过其在时间形成历史的流变，得以知晓现状，甚至能够预知未来。
那Web 1.0是什么呢？
他们说，记得静态HTML的WWW时代么？
（那个时代的WWW应用、人们的Web体验、对社会的影响如何？）
那么动态HTML和静态HTML下的Web相比，是多少版本？1.5？对了，他们是真这么叫的。
（在效果和影响上，与1.0相比，扩展和加深多少？）
要呈现的数据存储在数据库中，通过Web服务端的程序，应用户的请求，取出数据，加上事先设计的模板，动态的生成Html代码，发送到用户的浏览器那里。
他是1.0系列，应为用户在浏览器中所见和Web 1.0一样，它有0.5的升级，因为数据不是事先制作并发布，而是动态生成，和用户的需要交互生成。
那好，在加0.5，到Web 2.0，变化是在哪里呢？
（看到了正在崛起的和改变的，会继续朝着什么方向改变互联网和社会呢？）
更新：关于各个版本的差别，看看亚马逊的例子。
事情没有那么幸运，Web 2.0并不是一个具体的事物，而是一个阶段，是促成这个阶段的各种技术和相关的产品服务的一个称呼。所以，我们无法说，Web 2.0是什么，但是可以说，那些是Web 2.0。
WikiPedia的Web 2.0条目下列出了这些条件：
* CSS 和语义相关的 XHTML 标记
* AJAX 技术
* Syndication of data in RSS/ATOM
* Aggregation of RSS/ATOM data
* 简洁而有意义的 URLs
* 支持发布为 weblog
* RESTian (preferred) 或者 XML Webservice APIs
* 一些社会性网络元素
必须具备的要素有：
* 网站应该能够让用户把数据在网站系统内外倒腾。
* 用户在网站系统内拥有自己的数据
* 完全基于Web，所有的功能都能透过浏览器完成。
（以上内容引用自英文版维基百科）
虽然这只是一家之言，不过，对于其中谈到的几个要素，大家还是公认的。
- 基于RSS/ATOM/RDF/FOAF等XML数据的同步、聚合和迁移。
数据不再和页面和网站混粘在一起，它独立了，它跟着用户走。这是Web 2.0的很重要特征。这也是为什么Blog是Web 2.0的代表的原因。在网志上，常主角的是相互独立的一则则的网志。
独立，然后有物理表现。现在，就能让他们活跃起来。透过对XML数据的处理，这些内容能被自由的组合，被各种应用程序，不论是Web程序还是桌面程序等呈现和处理。
（更新：参看商业周刊的All Your Info in One Place）
当然，最重要的是背后的人。
- 社会性因素。
内容跟着人走，内容又能够被用户自由的组合，也就是说，用户能够自由的借助内容媒介，创建起一个个的社群，发生各种社会性的（网络）行为。
此外还有标签以及建立在开放标签系统之上的Folksonomy。
- 第三个公认的因素是开放API，这个技术性稍强些，得另花时间研习，可以先看看例子：amazon、flickr、google map等。
（Web 2.0是个大筐，装了好多东西）
从Web应用的产品/服务生产者角度来说，该如何创建Web 2.0的产品呢？
重要的是要抓住这么几点，一个是微内容（这里有定义），一个是用户个体。除了这两个最基本的之外，还可以考虑社群内的分享以及提供API。
微内容：英文是microcontent。用户所生产的任何数据都算是微内容，比如一则网志，评论，图片，收藏的书签，喜好的音乐列表、想要做的事情，想要去的地方、新的朋友等等。这些微内容，充斥着我们的生活、工作和学习，它的数量、重要性，还有我们对它的依赖，并不亚于那些道貌岸然、西装革履的正统文章、论文、书籍。
对微内容的重新发现和利用，是互联网所开创的平等、***、自由风气的自然衍生，也是互联网相关技术消减信息管理成本之后的一个成果。
我们每天都生产众多的微内容，也消费着同样多的微内容。对于Web 2.0来说，如何帮助用户管理、维护、存储、分享、转移微内容，就成了关键。
用户个体。对于Web 1.0的典型产品/服务来说，用户没有具体的面貌、个性，它只是一个模糊的群体的代名词而已。但是对于Web2.0的产品和服务来说，用户是个实实在在的人。Web 2.0所服务的，是具体的人，而不是一个如同幽灵般的概念。并且，这个人的具体性，会因为服务本身而不断地充实起来。
如何为这个具体的个体服务，是Web 2.0设计的起点。
因此，一类可以被称作Web 2.0的产品/服务将是这样：
服务于用户个体的微内容的收集、创建、发布、管理、分享、合作、维护等的平台。
这是表。
里呢，恐怕就设计到好些人提到的，微内容的XML表现；微内容的聚合；微内容的迁移；社会性关系的维护；界面的易用性等等。
其质，是否就是开源、参与、个人价值、草根、合作等等？
Web2.0是许多方面起头并进又相互牵连的一个新的阶段的到来。因此，不同的人，有着不同的看法。那么，对于Web开发人员来说，Web2.0意味着什么呢？
他们说Web2.0阶段，Web是一个平台，或者说，Web正在变得可编程，可以执行的Web应用。野心家们设想这个它的终极目标是Web OS。
Web 1.0时候，Web只是一个针对人的阅读的发布平台，Web由一个个的超文本链接而成。现在的趋势发生了变化，Web不仅仅是Html文档的天下，它成了交互的场所。
Web 2.0 Conference网站的横幅引用Jeff Bezos的话说“Web 1.0 is making the internet for people，web 2.0 is making the internet better for computers”。
具体来讲，他们说Web成为一个开发环境，借助Web服务提供的编程接口，网站成了软件构件。
这些，就是Web Service的目标吧，信息孤岛通过这些Web Service的对话，能够被自由构建成适合不同应用的建筑来。
一些例子：del.icio.us、flickr、a9、amazon、yahoo、google、msn等提供的编程接口衍生出的各种应用。
为什么要开放APIs，这涉及到集市中的商业方面的技术策略。当然，还有更深层的原因，那是什么呢？
这种交互不仅体现在不同的网站服务之间，同时还体现在用户和Web之间在浏览器上的交互。这也是为什么在美味书签的收藏中Web2.0和AJAX如此相关的一个原因。
在Web页面上使用桌面程序有的那些便利，真的是很享受的事情。这恐怕也是Web可编程的一个方面，Web页面不再是标记和内容混合那样的简单，它就是一个可以编程的地方（是这样理解吧？）
有人反对说，AJAX的使用对搜索引擎不友好，只有Web 1.0的站长才关心这个事情吧，在Web 2.0时候，站长应该关心的是用户参与的便利、用户的自由度，至于搜索，有RSS/ATOM/RDF等，更本用不着操心，Google不是已经顺应这个趋势，让大家主动提交了么？
可编程的第三个方面，是否在于Web应用和桌面应用之间的无缝连接趋势的出现？类似这里说的“从工具上，是由互联网浏览器向各类浏览器、rss阅读器等内容发展”
......
自己不是专业开发人员，对Web OS的学习就点到为止，下次换个方向，否则我非头大不可。
---------------------
cathayan和Live21说Web 2.0其实思路很古老，就是internet 1.0的回归。
Live21那里提到“关于概念的炒做应该不是一次两次的问题了”。
提到概念炒作，我还真见到过，今天在一篇报道中看到作为WEB 2.0的BSP的字眼，好笑得很。
不过，我真想说明，在目前中文Blog空间内能查阅到的学习、探讨Web 2.0的资料都不是炒作，因为包括我在内，大家都没有任何商业背景（注意，新闻报道中的那些Web 2.0除外）。
[Web 2.0是个历史学的概念，而非是个技术性的概念，它是对Web发展历史断代的成果。对这个概念的梳理，能帮助我更好的把握互联网正在发生的技术与文化。]
中文网志圈谈论的Web 2.0内容摘要：
- “我觉得最有价值的一个是， web应用的数据格式开始逐渐出现了交换“标准”...这些标准...更加容易被机器自动化处理...能帮助人更好地过滤和定制化信息。其次，更多的服务将以web service的形式来提供，...这使得web 服务可以被互相集成， 从而诞生更多新的服务...人的重要性被提高了。过去web更多注重在信息提供， 而现在的越来越多的应用更加关注人，也就是所谓“社会性”。此外web的可用性改进正在被越来越重视...”[老冒：朝web 2.0泼点冷水]
- “RSS逐渐成为在线内容提供服务的标准发行平台。Blog以及user-generated内容的兴起。My Yahoo提供的RSS整合型服务。同时提出了值得密切关注的一些发展中领域，其中包括搜索技术，个性化，User-Generated内容（包括 blog，评论，图像和声音），音乐，短视频和Accessibility(易访问性）”[Owen：Mary Meeker新作 - 关于Digital World的发展报告的摘取]
- “我们谈论的Web2.0带给我们的是一种可读写的网络，这种可读写的网络表现于用户是一种双通道的交流模式，也就是说网页与用户之间的互动关系由传统的“Push”模式演变成双向交流的“Two- Way Communication”的模式。而对于Web服务的开发者来说，Web2.0带来的理念是服务的亲和力，可操作性，用户体验以及可用性。”[Owen：BaCKpACK-体验可读写的Web服务]
- “web 2.0是一种可以被分发的信息概述，web文档被格式化成了web数据。我们不会再看到不同旧地信息，现在我们所注意到是一种聚合、再混合内容的工具。”[songzhen：也说Web 2.0的翻译]
- “从这些应用中可以看到：如果基于传统的HTML，同样的功能实现将变得非常复杂和不稳定，数据的再生产和交换成本是很高的。所以：RSS这个标准最终要的贡献就是使得互联网的大部分网站变得可编程：类似的例子还有Blog中的：TrackBack Ping等机制，这些机制都是依赖XML/RPC实现的。当初为Lucene设计一个RSS/XML的接口也是为了这个初衷，它使得全文检索服务可以轻松的嵌入到各种应用中，通过关键词将各种内容之间实现更丰富的关联(Well Referenced)。”[车东：RSS，简单协议使得互联网可编程]
- “聚合的可能性以及如何更好地聚合（通常来说，更好的聚合应该基于个人知识管理和人际关系管理）很显然应该成为新一代或者说web2.0架构的核心之一。还有，你会重新发现，恰好是分散带动了聚合，聚合促进了分散，通过聚合的思维，互联网的网络状变得越来越丰富和密集，web2.0就变得越来越有趣味，它将web1.0时代的硕大节点即门户网站不断消解，去努力创造一个更加和谐的自然网络图谱。”[Horse：rss，聚合的无数可能]
- “新的web2.0网站都依赖于用户参与、用户主导、用户建设”。[Horse：Web 2.0这个词]
- Keso：Web 1.0与Web 2.0的区别
- “表面上看，Bloglines取代了门户，成为一个新的中心，但这里有一个重大的区别。门户是只读的，它带有某种锁定的性质。你可以离开门户，但你无法带走门户的内容。Bloglines则完全不同，你觉得它好用，就会继续使用，有一天你不再喜欢Bloglines，你完全可以导出你的OPML，到另一个 RSS订阅网站，或者干脆用客户端软件浏览同样的内容。所以，像Bloglines这样的网站，是可写的，你可以导入，也可以导出。就像你对信息拥有选择权，对服务提供商也同样拥有选择权，没有人可以锁定你，主动权在你自己手上。”[Keso：再说信息选择权]
- “Flickr、del.icio.us、Bloglines等Web 2.0服务，通过开放API获得了很多有趣、有用的想法，并借助外部的力量，让用户获得了更好的体验。更多大公司也加入到开放API的潮流中，Google、Yahoo!、Amazon、Skype。Google桌面搜索今年3月才开放API，很快就产生了大量的创造，大大扩充了可搜索的文件格式。”[Keso：开放API]
- “归纳：web1.0天天谈门户，web2.0谈个人化；web1.0谈内容，web2.0谈应用；web1.0商业模式，web2.0谈服务；web1.0谈密闭、大而全，web2.0大家谈开放、谈联合；web1.0网站中心化，web2.0谈个人中心化；web1.0一对一，web2.0谈社会性网络；web1.0不知道你是狗，web2.0你去年夏天干了什么我一清二楚甚至想要干什么呢。。。”[van_wuchanghua：发现了N.HOOLYWOOD，我还知道你今年夏天要干什么]
- “我认为Web2.0有下面几个方面的特性: 个性化的传播方式. 读与写并存的表达方式. 社会化的联合方式.标准化的创作方式. 便捷化的体验方式. 高密度的媒体方式．”[飞戈：Web2.0与未来的网络]
- “用RAILS写的网站带有典型的读写网络的特征：RAILS创建的三个架构中的ACTIVE RECORD这个模块中，如果你读读它最重要的基类 ActiveRecord::Base，你会发现有CREAT,EDIT,SAVE,DESTROY这些方法已经天然包含在内了，这让实现一个数据库的CRUDS行为变得如此简单。由于这些类的方法直接和网页的名称映射到一起，这使得网页本身就像一个可以编缉的数据库的数据项。”[Blogdriver：RUBY ON RAILS，wEB2.0世界新生的创造力]
- “Greasemonkey一定名列前茅。这个通过User Script就能修改任何网页输出效果的插件极大的提高了用户阅读的自主性，一推出就引起了轰动，同时也引来了不少争议。”[Webleon：platypus，完全可写的互联网]
- “Web1.0到Web2.0的转变，具体的说，从模式上是单纯的“读”向“写”、“共同建设”发展；从基本构成单元上，是由“网页”向“发表/记录的信息”发展；从工具上，是由互联网浏览器向各类浏览器、rss阅读器等内容发展；运行机制上，由“Client Server”向“Web Services”转变；作者由程序员等专业人士向全部普通用户发展；应用上由初级的“滑稽”的应用向全面大量应用发展。 ”
Blog：个人媒体崛起
在Web 2.0 的世界中，Blog（中文翻译作“网志”、“博客”）绝对是个“招牌菜”，它已获得了广泛的知名度。 关于个人网站api接口编写和编写API的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 个人网站api接口编写的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于编写API、个人网站api接口编写的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。