Spring+SpringMVC+MyBatis+easyUI整合进阶篇（六）必定要RESTful吗？

做者：13
GitHub：https://github.com/ZHENFENG13
版权声明：本文为原创文章，未经容许不得转载。

写在前面的话

这个问题看起来就显得有些萌，或者说相似的问题都有些不靠谱，世上哪有那么多必定的事情，作开发都不必定作多久呢，因此说若是你有这个疑问的话是真真有点儿不着调，不过可能也就是随口一问吧，没有深究的必要。既然有人问这个，那么就再用一篇文章谈谈RESTful吧，既然谈，就不能只是谈其优势，也不能一味的吹捧，也讲一下本身的一些理解和不足的地方。

规范、易读、简洁？

Spring+SpringMVC+MyBatis+easyUI整合进阶篇（一）设计一套好的RESTful API
Spring+SpringMVC+MyBatis+easyUI整合进阶篇（二）RESTful API实战笔记(接口设计及Java后端实现)
Spring+SpringMVC+MyBatis+easyUI整合进阶篇（三）使用ajax方法实现form表单的提交
Spring+SpringMVC+MyBatis+easyUI整合进阶篇（四）RESTful API实战笔记(前端代码修改)
前文中已经谈了RESTful很多的优势，也作了代码更新，首先，REST强调HTTP应当以资源为中心，而且规范了资源URI的风格；规范了HTTP请求动做（PUT，POST等）的使用，具备对应的语义；遵循REST规范的Web应用将会得到下面好处：URL具备很强可读性的，具备自描述性；资源描述与视图的松耦合；可提供OpenAPI，便于第三方系统集成，提升互操做性；若是提供无状态的服务接口，可提升应用的水平扩展性；

总结下来：规范、易读，可是这两个优势也带来一些不尽如人意的"反效果":

• 由于RESTful规范较为明确且有必定的"强制性",这种限制反而致使设计uri变得复杂了，尤为是复杂的关系，操做，资源集合，硬性套用rest原则设计很是困难。
• 对于RESTful的争论无处不在，都在讨论正确性和规范性，即便和同事之间也会有相似的争执，当咱们在争论Restful风格到底如何设计才是正宗时，发现心中的困惑不只没有下降，反而增长了。
• RESTful思想及其所倡导的规范很正确，可是使用者的行为太刻意了反而致使这个东西变了味道，争来争去就是为了证实本身的理解和使用最"正宗"。

RESTful中的模棱两可

前一个段落可能有些过于概念化了，仍是举一些具体的例子吧。

案例一

其实，RESTful中也存在着许多的模棱两可，也有不少不是那么让开发人员舒服的地方，有人会去纠结查询、增长、修改、删除(对应的方法就是get、post、put、delete)，我的认为这并不彻底正确，由于这个想法把开发工做中的业务场景过于简单化和模板化了，咱们开发的功能就只实现这四类操做吗、若是遇到一些不能彻底对应上这四种方式的业务该怎么办呢？

• 发短信、支付、用户登陆认证，该用get、post、put、delete中的哪个HTTP动词？
• login和logout应该怎么REST化？
• 验证码发送该如何定义uri？

相似的问题还有不少，感受不少朋友会遇到相似的问题，内心面也有一些不肯定该如何去作，其实在理解了REST后，这些并非什么无解的难题，只是思惟方式要转换一下： login和logout其实只是对token或者cookie资源的建立和删除；业务的uri如何选择HTTP动词也要灵活变通，规范是死的，人是活的，按照本身的理解去作，若是后期发现错误即便纠正就行了。不过，虽然API如何编写是开发者的自由，但若是一个API在url里放一堆动词、资源设计混乱、各类乱用HTTP Method和Status Code，就太不像话了，规范嘛仍是要遵照的，说了这么多理解上的误差，其实代码质量才是最重要的，有些手段其实只是让代码看起来比较优雅的手段而已。

案例二

以上是针对于RESTful理解和设计上的一个例子，具体工做中还有其余的例子吗？也是不少的，好比，比较棘手的一个问题:跨域资源共享 CORS。

在实际进行跨域请求时，常常会遇到相似 No 'Access-Control-Allow-Origin' header is present on the requested resource.这样的报错:

这个问题并非由于RESTful引发的，也不能经过修改RESTful的规范去解决，举这个例子的缘由是由于在接口的RESRful化时也遇到过这个问题，解决办法就不在本文中列举了，有兴趣的朋友能够看一下跨域资源共享 CORS 详解这篇文章，之后有时间会把解决方案整理出来的。

一些须要重视的安全性问题

固然，不止是以上的两个问题，前一个段落主要是讲述了一下理解和具体使用上的问题，这一段讲一下可能引起的安全性问题。

遗漏了对资源从属关系的检查

一个典型的RESTful的URL会用资源名加上资源的id编号来标识其惟一性，就像这样:/users/{userid}，例如：/users/100

通常而言用户只能查看本身的用户信息，而不容许查看其它用户的信息。在这种状况下，攻击者极可能会尝试把这个URL里面的USER ID从100修改成其余数值，以指望应用返回指定用户的信息。不过因为这个安全风险太显而易见，绝大多数应用都会对当前请求者的身份进行校验，看其是不是编号为100的用户，校验成功才返回URL中指定的用户信息，不然会拒绝当前请求。

不经意间泄露的业务信息

以查看用户信息的RESTful URL为例：/users/100。因为用户ID是一个按序递增的数字，所以攻击者既能够经过ID知道目前应用中的用户规模，也能够分别在月初和月末的时候注册一个用户，并对比两个用户的ID便可知道当前这个月有多少新增用户。同理，若是订单号也是按序自增的数字，攻击者能够了解到必定时间范围内的订单量。

这类ID并不会给应用形成任何技术上的威胁，只是经过ID泄露出来的信息对于你的业务而言可能很是敏感。解决办法是不使用按序递增的数字做为ID，而是使用具备随机性、惟一性、不可预测性的值做为ID，最多见的作法就是使用UUID。

参考RESTful架构风格下的4大常见安全问题

选择适合本身的方式

Spring+SpringMVC+MyBatis+easyUI整合进阶篇（五）记录一下从懵懂到理解RESTful的过程
前一篇博客中也提到了不少其余的方式，好比传统的MVC开放形式，好比webservice，好比rpc调用，RESTful也只是其中的一种而已，这些选项中并无高下之分，无非是多种约定俗成的标准，传统MVC开发着舒服就按MVC模式来开发，习惯用RPC就用RPC，能理解和接受REST就用REST。

前几篇文章中描述了RESTful那么多的优势，如今又说大可没必要使用，前文又提到RESTful是好的设计实践，如今又是另一种说法，不是自相矛盾吗？

这是个人文章，我确定要按照个人一些想法写啊，可能有不对的地方，前文中提到的是好的设计实践也是个人我的想法和理解，这篇的开头就说了，不能只谈优势，因此又列举了一些不足吧，我写文章不是挑口水，很不必，选择适合本身的技术和规范就好。

套用网络上比较流行的一句话：

听了不少道理却依然过很差一辈子。

做为一名开发人员，本身动手去实践才是硬道理，别人说什么都不要全盘接受，你要想一想适不适合你，适不适合你目前作的项目，鞋合不合适只有脚知道，just do it!

结语

网站的持续运行须要各项基础设施的搭建，而服务期的续费和维护及各类配套服务的购买也须要必定的费用，但愿朋友们给予一点支持，谢谢！

支付宝：微信支付：

优势也好，缺点也罢，虽然看似也总结了很多，但都是我的看法，确定还有一些遗漏的地方没有讲清楚，还请见谅。

回答文章一开始的问题，是否是必定要用呢？是否是必定要遵循其规则呢？若是不能解决你所面对的问题，不能提升和提高代码质量、提高工做效率，其实大可没必要如此介怀，不用就是了。

首发于个人我的博客，新的项目演示地址：perfect-ssm,登陆帐号：admin,密码：123456

若是有问题或者有一些好的创意，欢迎给我留言，也感谢向我指出项目中存在问题的朋友，本篇主要讲述了我的对于RESTful的理解。

若是你想继续了解该项目能够查看整个系列文章Spring+SpringMVC+MyBatis+easyUI整合系列文章,也能够到个人GitHub仓库或者开源中国代码仓库中查看源码及项目文档。