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

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

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

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

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

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