深度理解HTTP与RESTFull API

 
前文我们一起讨论了开发Web API的教程，在后台收到了一些朋友的回复，有关于一些内容的指正，比如OpenAPI，以及对Thirft的看法。

我只所以称“Web API”，是因为我们返回的内容都是在HTTP的Body上反映的错误信息，一些错误处理是Web服务器返回给调用者，而非API本身。鉴于实用主义，亦不用吹毛求疵，通过Body中的JSON或XML返回也没有任何问题，很多技术团队都这么做，也没有什么不好，只是并不是完全的RESTFUL，而是叫Web API或JSON API。

关于HTTP

HTTP协议，在服务器与客户机建立连接后，规定了报文源流入与流出的规则，定义了报文头、首部、BODY，以及对服务器资源的请求方法 ，即GET/POST/PUT/DELETE/HEAD/TRACE/OPTIONS等，这7种武器并非所有服务器都实现了，常见的是前4种。HTTP的高扩展性，还允许我们实现其它的请求方法。

HTTP中的GET/POST/PUT/DELETE分别对应资源的查 ，改 ，增 ，删这4个操作。

根据HTTP规范，GET用于信息获取，PUB为更新信息，按规定应该是安全和幂等。
安全的意味着该操作用于获取信息而非修改。比如说GET，它仅仅是获取资源信息，就像数据库查询一样，不会修改，增加数据，不会影响资源的状态。
.幂等是对同一URL的多个请求应返回同样的结果。比如请求最新的新闻，不同的时间返回的数据不同的，但我们可以视为幂等。

对资源的增删改查操作，其实都可以通过GET与POST方法来完成，不需要用到PUT和DELETE。 很多开发者为了图方便，更新资源时用了GET，因为用POST必须要到表单，在测试时稍麻烦一些。

还有一个重要原因，一些Web MVC框架设计者们并未将URL当作抽象的资源来看待和设计，比如Servlet，Contoller等 。有的框架可能只支持GET和POST两种方法，开发人员基本就这样用了。

随着架构的发展，现在出现REST(Representational State Transfer)，一套支持HTTP规范的新风格。

综合而言，JSON API已经完成了大部分RESTFUL的工作，只不过像大多数开发者一样，我们使用GET和POST方法来完成了增删改查，而没有用到PUT和DELETE，另外返回的状态并非API返回的HTTP状态码，要么是JSON格式的状态，要么是Web服务器根据程序的严密度返回的状态码。

关于RESTFUL

RESTFUL是Representational State Transfer表述性状态转移的缩写，是Roy Fielding先生于2000年定义的，用来描述分布式系统架构的统一通信接口。它并不是一个严格规范存在。关于RESTFUL的几个定义，如下列表：

• 提供容易理解的目录结构URL[/][]表现形式为JSON或XML来表示数据对象和属性[/][]返回消息使用明确的HTTP方法实现（GET,POST,PUT,DELETE)[/][]无状态交互存储，客户端与服务器之间请求[/][]状态依赖并限制可扩展[/][]客户端保持会话

小结

在本篇中，我试图用“较科学”的态度，描述RESTFUL，考虑的并非全面，如有不周，还请各位留言，共同探讨。

下篇我们以高度实践的方式描述与实现一个可运行的RESTFUL API。谢谢大家观赏。

作者：杜江。21CTO（21cto.com）社区创始人。多年架构与管理经验。 著有《PHP5与MySQL5 Web开发技术详解》、《PHP5完全攻略》、《PHP与MySQL高性能应用开发》（机械工业出版社出版，各大电商平台和书店有售）。