用实践做总结，Restful API风格仅适用于业务逻辑简单的小型应用

       很苦恼编程界目前的一个现状：有很多人都说Restful不行或者不好，最后大多数人都被Restful的支持和拥簇者怼了回来，说你根本就不懂得什么是Restful，因为在Restful的世界里，一切你要操作的对象都可以抽象成资源，你们这些说Restful不好的人，根本就没有理解Restful的精髓，在这种情况下，甚至很多人深受Restful为害之苦，却不敢站出来发声；

       为什么会出现这种情况呢？因为大多数人都在为自己喜欢偷懒找借口，不愿意去花时间实现更多不同动作所对应的接口，这样造成了一种很不好的后果，后端很多不同逻辑的代码耦合在一个接口里，让前端人员调用时还要用参数控制不同的逻辑，而后端的代码耦合度太高，也造成了后期难以维护（这么说肯定有人会反驳，说你可以把耦合的逻辑单独抽离成一个新的资源，开放个新的接口啊，可是，真正做到这点的人，其实不多，因为大家都懒）。最后造成的结果，一个update方法，里面耦合了好多个逻辑，搞得一个方法几千行，根本没办法维护；

       一般情况下，多数小型应用都是IO密集型的，也就是针对数据库做一些基本的CURD操作，基本上都是对一个资源的CURD几个基本操作，这种情况用Restful可以满足业务需求，而且条例清晰，所有的CURD都是对一个资源的操作，那么只要用对应的POST、PUT、GET、DELETE请求方式就可以区分想要做什么了；

       而真实的情况下，没有一个应用是只有对资源简单的增删改查几种逻辑的，举几个例子：

       一、审核功能，这是一个动做，是对资源操作的特殊动作，是特定的某些拥有审核权限的用户才能操作的一个动作；逻辑上这个动作就是对资源审核状态的修改，但又不能当作修改来对待，因为要判断用户权限，不是有修改权限就一定有审核权限的，所以就必须拆离出来一个接口（不抽离后期维护会更惨），单独来实现这个审核的动作，那么问题来了，新建的接口如何命名？名词命名体现不出来接口的用意，动词命名又不符合Restful风格，很尴尬吧。

       二、code的问题，Restful提倡直接返回网页状态码，这样前端就不需要去判断返回信息里面的具体内容了，可以跟据状态码直接给用户返回提示信息，而且在性能上有一定提升（其实就是节省了一步获取返回信息的开销）。我试问一下，这样做真的好吗？如果你用H5技术封包了一款app，是这样做的，那么有一天发现有一些地方还是要获取一下后端的返回信息的，比如500错误时，我不能直接告诉客户，服务器报错，我需要返回一个合理的解释给客户看，这个时候难道还要为了这件事情，新发版一版app，然后让用户统一升级一下吗？再说性能上的开销，http的最大开销无非就是几次握手的过程，几次握手都完成了，就差一步取值了，你却舍弃了取值，美其名曰节省性能，在这个网速发达，硬件发达的时代，缺这点性能吗？其实所有接口返回，无非两种状态，成功、失败，失败又分参数校验失败、返回信息失败、权限校验失败，何必弄那么多个code码折磨人呢，何况好多程序员根本就不能合理使用这些code码呢。

       三、资源关联问题，明明是关联密切的一个事，却抽象出来两个资源，让前端人员实现一个事情却要请求多次不同接口，从哪个角度看都是浪费，比如我返回用户列表的时候，需要关联显示一个用户隶属部门的名称，明明可以后端一次性返回到一个列表里，却让前端人员调用完用户接口再去调用部门接口，再把数据组装到一起然后渲染到页面上，是不是在浪费开发时间、浪费服务器的性能和网络开销，归其原因还是后端程序员太懒。

       做为一个10几年得老程序员，告诉一下大家应该如何实现优质的代码，好多程序员入职新公司都会接手烂代码，究其原因代码烂在哪里？多数情况是代码里没有做合理的业务抽离，把多套逻辑混在一起来实现，搞得一个方法几千行，可读性大大降低。做为一名程序员，大家都应该遵循一个原则，就是一个方法只干一件事，一件事只让一个方法干，大事拆成小事干。这样你会发现，你写得程序会变得非常简单易懂，一个方法代码行数一般情况不会超过200行，方法名以动词命名，让人一看就知道是干什么的，甚至不写注释都能很容易看懂，不是有句话说，好得代码是最好得注释码?

      最后，希望大家绕开Restful这个坑，不是谁都能优雅得使用Restful的，传统的接口方式还是很值得推荐的，一看接口的地址就知道这接口是干什么的，每干一个事都有和它对应的接口，这样不是很好吗？文章标题里说的Restful仅适用于小型应用，其实是因为，你做个小型应用也不至于有多少坑等着你踩，用用Restful就当学习了吧，了解一下它的机制之后，你会发现，它并没有传说的那么好。