RESTful架构由来已久，不过最近好像restful这个词出现的很频繁。不是很清楚是因为我现在用restful风格写程序的孕妇效应是单页程序开发流行造成的。其实一开始并不想写这篇文章，因为网上有很多restful相关的文章，而且都写的不错，参考价值比较高。但是我仔细梳理了自己看的文章，发现大家基本都是讲restful的理论经验，对于restful实际编程中的一些经验总结似乎并没有过多提及。而关于这方面的经验总结，我也想找找参考，但是没找到。因此，我写了这篇文章，希望有的人能得到一些参考（因为是我个人的实践，可能有些不符合主流的地方，还请大家多多包涵或指出）。另外，在这篇文章中，我不会讲如何设计底层的restful支持（如何设计restfulframework）。要说到这里，内容就太长了。我主要讲应用层，也就是一些具体的业务逻辑。当然，会解释一些基本的扩展。资源说到restful，就不得不说到资源。restful的每一个接口都应该对应一个资源。那么，在restful中，“资源”这个词其实应该被看作是一个抽象的概念，而这个“资源”所包含的资源不仅仅是常规意义上的资源。我觉得用另一种方式把这个资源称为对象可能更容易理解。当然，首先，我们其实应该说说资源是什么。资源包含很多东西，从图片到音频、视频等数据，还有文本等等。换句话说，存在于服务器上的数据是一种资源。但是，单单谈资源意义不大。应该说资源的表示才有意义，或者说数据的表示才有意义。这在这里非常重要。这就涉及到了后面要讲的restful风格设计。一般来说，我们打开一个URL看到的是一个完整的html界面，但实际上这个html界面就是一个资源，html中显示的图片、音频、视频等都是资源。说到这里，可能有人在开发过程中误解了一些东西，认为restful风格获取的资源是服务器返回的json数据。对此，我们要明确几个概念：数据类型：服务器返回的数据类型，如html、图片、视频、Excel表格、world文档等；传输方式：异步和同步；串行和并行传输：串行传输是等待一个数据传输完成再传输另一个数据，并行是同时执行。这三件事我就不细说了。说起来就比较复杂了。我就说一下串行和并行以及异步和同步的一般解释。很多人认为异步就是并行执行，或者异步理解为并行执行，其实不一定。异步执行只能是指在某个进程执行的同时可以执行其他任务，减少阻塞。请求方式常用的请求方式大致有：GET、POST、PUT、DELETE、OPTIONS。GET：接口从字面意义上理解，就是获取数据。我们在设计的时候，GET应该包括两种数据获取方式，一种是获取整体数据列表，一种是根据指定的ID获取数据。POST：对于新数据，这种请求方式设计的接口是针对新数据的；PUT：是修改数据的接口，如果要修改资源的数据，那么程序应该考虑在这个接口；DELETE：简单易懂，该请求方法对应界面上的删除操作；OPTIONS：这个接口比较有意思，通常这个接口是为了返回当前接口的一些信息，比如哪些字段可用，哪些字段允许请求，哪些字段不允许等等。那么后端业务逻辑程序应该提供五个基本接口，例如：interfaceApi{publicfunctionindex(){}//GETlistinterface/apipublicfunctionview(){}//GETsingledatainterface/api/:idpublicfunctioncreate(){}//POST创建接口/apipublicfunctionupdate(){}//PUT修改接口/api/:idpublicfunctiondelete(){}//DELETE删除接口/api/:id}业务逻辑设计思维方向好了，说了这么多，那么这一点大概是比较关键的事情了。可以看到上面的代码界面。我在下面的评论中做了请求方法和功能描述。我们来看看更新界面。需要注意的是，通常设计的修改接口后面必须跟指定的数据id，其中：id指的是资源id参数。从这个角度来看，似乎对资源的修改是有一定局限性的，当然删除也是一样。那么，我想很多人应该开始有疑问了：“卧槽，我想批量修改，怎么办？这个restful也太局限了吧？”。是的，一开始我也是这么想的，后来仔细想想，我发现不是这样的。上面我说了，服务器端的任何数据都是一种资源，在restful中应该把resources看成抽象的意思。上面没法解释，其实这跟程序设计中的一些问题有关。首先假设有一个例子，我们要批量删除一堆商品数据。按照传统的思路，用户批量选择，然后把这串id传给后端，然后后端根据这批id删除。我这样说，并不是表示这套思路在restful上行不通。首先，我们要确定这是正确的，但我们要做的是跳出这个时期设计的另一种思维。也就是这个时候，我们把product当作资源操作，这个时候，我们应该把“删除product”当作资源，而不是product。那么在我们设计界面的时候，就具有很大的意义了。我们把“删除商品”当成一种资源，暂时把这个接口定义为：/delete-goods。那么delete就是对应的post接口，即创建“删除商品”，然后undodelete就可以对应删除界面，即delete“删除商品”。上面的描述可能有点啰嗦，但实际上就是这样。如果我们这样设计，我们就遵循了restful标准。事实上，交互过程与传统的交互过程没有太大区别。唯一不同的是观念的转变。分析以上，其实我们应该得出一些结论：在做restful设计的时候，编程思维应该进行一定程度的转变，思考在不同的场景下，什么应该是资源，什么应该算是资源？做restful应该把逻辑拆分的更清楚。没有逻辑对象只能做五件事：看列表数据、看个别数据、添加数据、修改数据、删除数据。上面虽然说了删除，其实批量编辑也符合这种思路，包括我之前回答过的一个问题，就是批量阅读消息的操作也符合这种思路。其他的restful交互一般遵循一些数据结构协议或HTTP状态值。例如，不同的操作结果对应不同的HTTP状态值，发生错误时返回指定的错误信息给前端提示等。当然，为了完全遵循自然语义，设计restful接口的还可以使用请求资源列表和复数请求方式（语言中的单复数）等。不管怎么变，我觉得最基本的就是不同的请求方式对应的不同的操作问题，所有的操作都对应同一个接口。以上就是我对一些应用场景的理解和总结，欢迎大家互相交流。
