深度理解HTTP与RESTFull API


rest-api.jpeg

 
前文我们一起讨论了开发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高性能应用开发》(机械工业出版社出版,各大电商平台和书店有售)。
 


4 个评论

PUB是不是写错了?PUT
老师能否写一篇关于gateway api的设计文章/微笑
理论层面看非常棒,期待下面的实例。。。
理论分析胜过粗略简单的事例描述

要回复文章请先登录注册