《RESTful Web APIs》读后感

《RESTful Web APIs》读后感


由于想理清楚REST术语的确切含义，以及大多数场景下REST代指了什么，是否有人滥用的情况，我找了一些专门讲REST的书来学习。下面是我对REST学习后的一些理解和总结。
从精准定义上讲，REST的意思是“表述性状态传递”（英文：Representational State Transfer，简称REST）。但这种定义很难理解，并且很难和我们日常说的“REST接口”联系起来。而实际上简单来讲，REST是指开发一个REST Web接口时让合理选择使用GET、POST、HEAD、PUT、DELETE、OPTIONS等谓词，对于合适业务操作动作，选择合适的谓词，而不是一味的只是使用GET和POST。比如在执行的删除和更新操作时也用GET和POST，从设计的角度讲，是不优美的，因为有更合理的设计方案。


HTTP、Web被使用了这么些年，以前用GET和POST也都干的好好的，为啥忽然就有人开始嚷嚷着用PUT、DELETE等所谓的“REST风格”？ 我个人分析的结论是：随着这几年移动Web的发展，很多系统的后台都想既支持PC又支持移动设备，而又只写一套后台程序，这样就需要同一套接口。而基于HTTP协议的接口是最容易被复用的。在基于HTTP的协议里，SOAP协议又太重了，为了传输一点小小的业务上的数据，就需要传输大量的通信数据。所以逐渐的基于原始HTTP协议，采用JSON格式的传输流行起来了。又因为JSON被JavaScript天然支持，一切就都酷毙了！


后来使用RoR开发的Github之类的网站的页面的URL风格开始美化，设计的简短合理清晰，并开始引领了潮流，很多的Web设计开始效仿，摒弃了URL中的update_article.do?id=xxx&date=xxx之类的长篇的&连接变量的风格，而是代之PUT xxxx/articles/2015/3413之类优美的URL。


前端JS框架和后端语言框架也都开始对这种REST风格的增删改查大加支持，新的框架和库方法中内置了简便的操作，使得整个的设计刮起了一种简洁之风。而不是把所有的语义都塞进了只有GET和POST的URL中。


在《RESTful Web APIs》这本书中提出了REST应用的三级成熟度模型，如果能达到第一级，即会认为这是一种REST风格，即有清晰的资源对象，每个资源有对应的标识符和表达。第二级是对资源的操作使用合适的HTTP谓词。比如说一个订单它的URL就是http://xxxx/xxx/orders/201603019870，这个URL就是这个订单的唯一标识，我如果从无到有创建出来这个订单，我就去POST这个URL，我如果想修改这个订单的内容，我就去先把它GET下来，然后改完内容后再PUT回去，我如果想删除订单就去DELETE它，我如果想查询我对这个订单的操作权限就去用OPTIONS去访问它。如果需要达到成熟度模型最高级第三级，就是把REST接口的业务含义变成自我表述的了，这样就可以摒弃接口文档了。我只需要调一个全局的接口，这个全局的接口就会返回我可用的所有的接口，我再访问其中的某个接口时，还会返回给我更多的可用的接口的指示，这样我就不需要查看接口定义文档，我只通过接口调用就能知道这个系统都提供了哪些接口，这样客户端和服务器端就解耦的更彻底，服务器端的接口升级和变更都不需要再专门以开发文档的形式告知客户端了。


因为REST和HTTP的创造者是用一个人，并且REST的思想出现在HTTP设计之前，HTTP的创造者在设计HTTP的时候就是使用的REST思想。REST只是是一种思想，所有的其他的非HTTP的设计也可以使用这种思想，所以说REST自身所代指的东西是很宽泛的。但因为HTTP是同一个作者发明的，所以HTTP又是REST的典型代表。


因为HTTP最早的设计是无状态的（即无会话风格）的，它不像TCP/IP的套接字那样，每次都需要先三次握手，建立一个通道，然后在相同的通道下开始传递数据。而是每次传输完就结束了，每次HTTP请求都是平等不相关的。这样的设计有很多的好处，当然也有一些不便之处，导致了人们后来在HTTP的基础上增加了COOKIE，SESSIONID之类有会话性质的特性，这些都是反REST的。所以在设计一套REST风格的应用时一定要摒弃这种有会话的思想，只有这样，设计出来的服务才通用、容易复用、方便测试、易于升级和维护、简单易懂和清晰优美。