写在前面的话
这个问题看起来就显得有些萌，或者说类似的问题都有些不靠谱，世上哪有那么多必定的工作，做开辟都不必定做多久呢，所以说如不雅你有这个疑问的话是真真有点儿不着调，不过可能也就是随口一问吧，没有深究的须要。既然有人问这个，那么就再用一篇文┞仿谈谈RESTful吧，既然谈，就不克不及只是谈其长处，也不克不及一味的吹捧，也讲一下本身的一些懂得和不足的处所。
规范、易读、简洁？
Spring+SpringMVC+MyBatis+easyUI整合进阶篇（一）设计一套好的RESTful API
Spring+SpringMVC+MyBatis+easyUI整合进阶篇（二）RESTful API拭魅战标记(接口设计及Java后端实现)
一般而言用户只能查看本身的用户信息，而不许可查看其它用户的信息。在这种情况下，进击者很可能会测验测验把这个URL琅绫擎的USER ID大年夜100修改为其他数值，以期望应用返回指定用户的信息。不过因为这个安然风险太显而易见，绝大年夜多半应用都邑对当前请求者的身份进行校验，看其是否是编号为100的用户，校验成功才返回URL中指定的用户信息，不然会拒绝当前请求。
Spring+SpringMVC+MyBatis+easyUI整合进阶篇（三）应用ajax办法实现form表单的提交
前一篇博客中也提到了很多其他的方法，比如传统的MVC开放情势，比如webservice，比如rpc调用，RESTful也执偾个中的一种罢了，这些选项中并没有高低之分，无非是多种商定俗成的标准，传统MVC开辟着舒畅就按MVC模式来开辟，习惯用RPC就用RPC，能懂得和接收REST就用REST。
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其实只是对session资本或者cookie资本的创建和删除；营业的uri若何选择HTTP动词也要灵活变通，规范是逝世的，人是活的，按照本身的懂得去做，如不雅后期发明缺点即使改┞俘就好了。不过，固然API若何编写是开辟者的自由，但如不雅一个API在url里放一堆动词、资本设计纷乱、各类乱花HTTP Method和Status Code，就太不像话了，规范嘛照样要遵守的，说了这么多懂得汕９依υ?差，其实代码质量擦?鲱重要的，有些手段其实只是让代码看起来比较优雅的手段罢了。
案例二
以上是针对于RESTful懂得和设计上的一个例子，具体工作中还有其他的例子吗？也是很多的，比如，比较棘手的一个问题:跨域资本共享 CORS。
在实际进行跨域请求时，经常会碰到类似 No 'Access-Control-Allow-Origin' header is present alt="跨域" />
这个问题并不是因为RESTful引起的，也不克不及经由过程修改RESTful的规范去解决，举这个例子的原因是因为在接口的RESRful化时也碰到过这个问题，解决办法就不在本文中列举了，有兴趣的同伙可以看一下跨域资本共享 CORS 详解这篇文┞仿，今后有时光会把解决筹划整顿出来的。
一些须要看重的安然性问题
当然，不止是以上的两个问题，前一个段落主如果讲述了一下懂得和具体应用汕９依υ?题，这一段讲一下可能激发的安然性问题。
前一个段落可能有些过于概念化了，照样举一些具体的例子吧。
案例一
漏掉了对资本从属关系的检查
一个典范的RESTful的URL会用资本名加上资本的id编号来标识其独一性，就像如许:/users/{userid}，例如：/users/100
不经意间泄漏的营业信息
以查看竽暌姑户信息的RESTful URL为例：/users/100。因为用户ID是一个按序递增的数字，是以进击者既可以经由过程ID知道今朝应用中的用户范围，也可以分别在月初和月末的时刻注册一个用户，并比较两个用户的ID即可知道当前这个月有若干新增用户。同理，如不雅订单号也是按序自增的数字，进击者可以懂得到一准时光范围内的订单量。
这类ID并不会给应用造成任何技巧上的威逼，只是经由过程ID泄漏出来的信息对于你的营业而言可能异常敏感。解决办法是不应用按序递增的数字作为ID，而是运器具有随机性、独一性、弗成猜测性的值作为ID，最常见的做法就是应用UUID。
推荐阅读
微信是一款功能强大年夜的聊天软件，应用微信聊天的人越来越多，很多时刻看到一些小视频经常会和同伙分享，那么在微信中看到小视频保存在哪里呢?可能很多人都不知道保存在那个文件夹?不过>>>详细阅读
地址：http://www.17bianji.com/lsqh/37937.html
1/2 1
网友点评
精彩导读
科技快报
品牌展示