RESTful实践（具体应用）思考

RESTful这种架构已经具备很长的时间和历程了，但彷佛最近restful这个词出现的频率特别高，目前不是很清楚是由于我自个儿如今是以restful风格写程序产生的孕妇效应，仍是单页面程序开发的流行形成的。

其实一开始我也是不想写这篇文章的，由于网络上与restful相关的文章挺多，并且都写得挺好的，都具备比较高的参考价值。可是我仔细梳理了我所看过的文章，发现你们基本上讲的是restful的理论经验，好像并无过多的说起restful实际程序设计上的一些经验总结。并且关于这方面的经验总结我曾经也想找找来作参考也并无找到，所以，我写这篇文章，但愿一些人能获得一些参考（由于是我我的实践，可能有些不符合大流的地方，那就请多多包涵或者指出来了）。

另外这篇文章我不会去讲一些底层restful支持怎么设计（restful框架怎么设计），要说这个的话，那么内容太长了，我主要讲应用层面的东西，也就是具体业务逻辑的一些东西，固然会作一些基本的引伸讲解。

资源

说到restful就不得不说资源这个东西了，restful的每个接口所对应的应该是一个资源。那么，在restful里面，“资源”这个词其实应该算是一个抽象概念了，这个“资源”所包含的资源就不只仅是常规意义上的资源了。我以为换一种方式叫法，把这种资源叫作对象，可能会更加方便理解。

固然，首先咱们其实应该说一下什么是资源。资源包含的东西不少，从图片到音频、视频等数据，以及文本等都是资源。也就是说，服务器上存在的数据就是资源。

可是，单独说资源没有太多意义，应该说资源的表现方式才有意义，或者说数据的表现方式才有意义，此处挺重要的，这个涉及到后续我说的restful风格设计方面的东西。一般来讲，咱们打开一个URL所能看到的就是一个完整的html界面，而其实，这个html界面就是资源，html所显示出来的图片、音频、视频等等都是资源。说到这里可能有些人在作开发过程当中对于一些东西具备误解，认为restful风格所获取的资源是服务端返回json数据。关于这个，咱们应该搞清楚几个概念：

1. 数据类型：就是服务端返回的数据类型，如html、图片、视频、Excel表格、world文档等等；
2. 传输方式：异步和同步；
3. 串行和并行传输： 串行传输是等一个数据传输完成再传输另一个数据，并行是同时执行。

这三个东西我就不展开细说了，提及来比较复杂，我就说一下串行和并行与异步和同步的一个大体讲解就行了，不少人以为异步是并行执行的，或者说把异步理解成并行执行的，这其实不必定，异步只能说执行的时候在某个流程执行的时候能够开始其余任务执行，减小阻塞。

请求方式

经常使用的请求方式大体就是：GET、POST、PUT、DELETE、OPTIONS。

GET：接口从字面意识理解，就是获取数据的，而咱们在设计的时候，GET应该是包含两种数据获取方式，一种是获取总体数据列表，一种是根据指定ID获取数据。

POST：是新增数据用的，此请求方式设计的接口是新增数据；

PUT：是修改数据接口，若是要对资源作数据修改，那么程序应该考虑放在这个接口中；

DELETE：很容易理解，这个请求方式对应的是对接口的删除操做；

OPTIONS：这个接口蛮有意思的，一般这个接口设计为返回当前接口的一些信息，好比有哪些字段，哪些字段容许请求哪些字段不容许等。

那么后端的业务逻辑程序应该向外提供基本的五个接口，如：

interface Api {
    public function index() {} // GET 列表接口 /api
    public function view() {} // GET 单个数据接口 /api/:id
    public function create() {} // POST 建立接口 /api
    public function update() {} // PUT 修改接口 /api/:id
    public function delete() {} // DELETE 删除接口 /api/:id
}

业务逻辑设计思惟方向

嗯，说了以上一大堆，那么这个点估计才是比较关键的东西。

能够看以上的那段代码接口，我后面的注释作了请求方式和功能性说明，来看一下update这个接口，这个接口须要注意的是，一般设计的修改接口后面必需要带上指定的数据id，这里的:id指的是资源id参数。从这里来看，彷佛对于资源的修改具备必定的局限性，固然删除也如此。而后，我想不少人应该就开始有一个疑问了：“卧槽，老子要作批量修改，咋办？这restful也太局限了吧？”。

对，我开始就是这么想的，后来通过个人思考，我发现并非这样。我上文提到，服务端任何数据都是资源，并且资源在restful里应该算是一个抽象的意义。上文无法作说明，但其实，这个是关乎到程序设计上的一些问题的。

首先，咱们来假设有这样一个例子，咱们要批量删除一堆商品数据。按照传统的思惟，用户批量选择，而后把这一堆id传递到后端，而后后端根据这一批id来进行删除。我说这个，并非要表达在restful里这套思惟行不通，首先应该确定这是对的，可是，咱们要作的是跳出这期间设计到的另一个思惟。也就是此时咱们把商品当作一个资源操做，此时，咱们应该把“删除商品”当作一个资源，而不是商品。那么咱们在设计接口的时候，就具备很是大的意义了。咱们把“删除商品”当作一个资源，暂且把这个接口定义为：/delete-goods。那么，删除就是对应的post接口，也就是建立“删除商品”，那么撤销删除能够对应delete接口，也就是删除“删除商品”。

以上描述得可能有些拗口，但实际上就是这样，若是这么设计，咱们遵循了restful的标准，其实交互流程与传统没有太多差异，惟一的差异就是思想的转换。分析以上，其实咱们应该得出一些结论：

1. 作restful设计的时候，程序设计思惟应该要作必定的转换，在不一样的场景思考到底什么才应该是资源，应该把什么当作资源？
2. 作restful应该把逻辑拆分得更清晰，没个逻辑对象只作五件事情：看列表数据、看单个数据、增长数据、修改数据、删除数据。

以上我虽然是就删除来讲的，其实批量修改等也贴合这种思想，也包括我以前回答的一个问题，就是批量阅读消息这种操做也贴合于这种思想。

其余

restful交互通常会遵循一些数据结构协议或者HTTP状态值，好比不一样的操做结果对应不一样的HTTP状态值，且出错会返回指定的错误信息方便前端进行提示等。

固然restful接口的设计为了彻底遵循天然语义也能够采用请求资源列表采用复数请求方式（语言中的单数词和复数词）等等。

无论怎么变化，我以为最基本的仍是不一样的请求方式对应的不一样操做问题，全部的操做对应的仍是同一个接口。

以上就是个人一些应用场景的理解和总结，欢迎你们一块儿交流。