记录一下从懵懂到理解RESTful的过程

前言

Spring+SpringMVC+MyBatis+easyUI整合进阶篇（一）设计一套好的RESTful API
Spring+SpringMVC+MyBatis+easyUI整合进阶篇（二）RESTful API实战笔记(接口设计及Java后端实现)
Spring+SpringMVC+MyBatis+easyUI整合进阶篇（四）RESTful API实战笔记(前端代码修改)

前文中提到了RESTful设计，后端实战及前端代码的修改，写完之后本来想写一下对RESTful的一些看法的，但是写着写着跑题了，最终是写成了不同阶段对于RESTful的认识和感受，包括第一次听到这个概念，第一次使用这个规范.....一幕幕回想起来也是很有意思的经历。

初识RESTful

第一次知道这个概念应该是在2014年的时候吧，那时候的我入行不久，接触JavaWeb开发也只是在入门的水平，做过几个小的官网项目，开发模式也是跟着公司的开发来，用比较传统的MVC开发模式，技术选型就是Jsp+Servlet，因此对REST这种思想或者说对于异步调用接口的方式可以说是一窍不通。

看着REST风格的接口URL，当时唯一的想法就是，不就是把".do"去掉吗？有什么难的？等等，如果把".do"去掉还怎么拦截Servlet的请求？

这就是初识RESTful的情形，第一次接触RESTful的时候，我的关注点在URL和Servlet拦截配置上，以那时的技术水平和开发经验来说，似乎也只能意识到这么多，对于RESTful的理解也仅仅在URL的格式不同罢了，至于其他的理解和想法？不存在的。

第一次在项目开发中结合REST实践

渐渐地，随着项目经验的增多，以及自学了一些Java中流行的开发框架，慢慢的就不再选择使用Jsp+Servlet来开发新项目了，在项目积累中也学到了关于异步调用的知识，学会了使用ajax异步调用接口渲染页面，这个时候还是没有想过接口的RESTful化。

第一次试着将RESTful运用到项目开发中是在挺久之后了，一位新同事在看了以往的代码后，提出想要改动代码，相对来说他更加有开发经验，因此就跟着他开始做代码修改的工作，那时候嘴巴里也整体RESTful来，RESTful去的，其实嘛，也不是很懂，这是真心话，只是听着老师傅说这么做是去优化代码的，作为菜鸟的我一听到项目优化，肯定是乐意去做的。

这是当时的指导文档，只截了一部分：

项目完成后，改动其实挺多的，配置文件，代码风格...不过这些都是代码层面的，暴露出的比较明显的变化就是接口URL的改变，接口中的".do"、".action"没了，调用时也增加了调用方法，与之前相比，逼格好像提高了一些！这是当时印象最深刻的感觉了。

但是依然有很多比较搞笑的地方，因为是第一次使用，很多概念其实也不是特别了解，http动词啊，状态码啊，包括REST其实是四个单词首字母的组合我都不知道，反正第一次使用完全就是个愣头青，依着葫芦画瓢，但是也并没有画的很像。

存在的问题很多：

• uri不规范，url命名比较随便
• 不理解http动词，post和get方法乱用
• 没有错误处理
• 也没有跨域处理
  .....

回忆起这次经历，总结起来就是画虎不成，不懂装懂，完全是图个新鲜。不过没有这次啼笑皆非的经历我也不会去学习这方面的知识，也算是迈出了第一步吧，虽然样子比较难看。

RESTful+前后端分离是一个良好的开发实践

真正大规模使用和深入学习是在一次项目的重构工作中，由于当时的开发人员配置还算可以，就计划将项目拆解为前后端分离的模式，对于开发人员的分工和代码结构都打算做一次大的改变。一开始依然是懵懵懂懂，随着学习和使用的深入，也不断的对之加深了解，对其中的一些知识点和规范也有了自己的看法，比如接口命名，http动词的使用，接口的版本控制，权限验证....

由于对RESTful的真正了解是在一次项目的前后端分离实践中，因此对REST的认识都多多少少的带有一些前后端分离的想法，并不是说REST一定要和前后端分离这个概念产生必然的联系，REST用在普通MVC项目中可以吗？是可以的，前后端分离的项目中调用的接口不符合REST规范可以吗？也是可以的。其实，REST+前后端分离是一个相对来说不错的一个开发实践，对前后端的开发人员都比较友好，当然，这都是个人想法，在实际工作中也是受到了较大的影响，后来的大部分项目开发也基本上都是遵循这种方式，除非有特殊情况。

不仅仅只有RESTful

在网站或者应用的开发中，数据传输方式不仅仅只有RESTful一种规范，比如传统的MVC模式的开发模式中，就是将数据放入model中来实现数据的传输，当然，这种方式不是基于接口的方式，基于接口的调用还有webservice方式，我没有接触过webservice开发就不多讲了，至于其他的还有基于RPC框架的调用方式。

在服务化的讨论中目前最风光的应该就是SpringCloud和微服务了吧，由于在SpringCloud技术栈中，各个微服务间调用的方式就是http+json方式，可以很简单的设计为RESTful架构，因此RESTful概念也随之又变得火热和流行起来。

说到这里呢，又引出了一个比较，就是在项目服务化过程中，是选择使用阿里开源的Dubbo还是Netflix开源的SpringCloud技术栈呢？

为什么提出这个问题呢，因为这两个技术栈恰好是分别使用了基于http+二进制序列化的RESTful规范(SpringCloud)和基于tcp+二进制序列化的RPC调用方式(Dubbo)，Dubbo是国内较为流行的服务化框架，资历也较老，而SpringCloud则是目前炽手可热的后起之秀，关于这二者的比较怕是可以写出不知多少篇文章了，在这里提到二者之间的比较也是想说明技术选型其实不用拘泥于一种。

REST只是众多方式中的一种罢了，方法和技术选型真的很多，因此不要标榜其中任何一种方式，也不要鼓吹其中任何一种技术，没必要，选择适合你的就好，如果实在不知怎么选，干脆都用一下就好了。

结语

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

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

如果你想继续了解该项目可以查看整个系列文章Spring+SpringMVC+MyBatis+easyUI整合系列文章,也可以到我的GitHub仓库或者开源中国代码仓库中查看源码及项目文档。