对REST与RESTful的再次学习

今天下班回家时，一个组员在QQ上面问我是否知道REST架构，我当时楞了几秒，回想了两年前第一次学习RESTful的场景。非常尴尬，很多东西我都忘记了。

在短暂的回忆之后，我在手机上打出了这样一段文字“我目前还没法很好的解释，简单说它是一种面向资源的架构设计风格”。接下来一种我想到了，这样的主流框架在定义路由的时候都采用了这样的设计，甚至的、的都不例外。但是这究竟是一种怎样的设计呢？我无法用语言描述清楚。

在我看来一样东西是否理解，不取决于是否会使用，而是能够向不理解的人讲述清楚。从这个观点上来看，我对RESTful算是一点也说不上理解了。

在网上查了些资料，非常多的人为REST与RESTful提出了自己的理解，在中心思想不变的情况下，又各自演化出了各自对REST思想的解读。为什么会这样呢？因为提出REST思想的是一篇学术论文中的某个章节，而学术论文本身就是晦涩难懂的，所以才会出现了五花八门的各自解释。

总结了一下网上各种各样的说法。发现对REST思想的理解可以分为几个层次。

初级层

并不是完全说这一层很low，而是他能用一句话进行概括性的总结。

总结一句话就是：用URL定位资源，用HTTP动词来描述操作，通过HTTP的响应码来感知结果。

这是目前我认为的对REST架构设计的最精简的解读了。但是他并没有说明我们该如何去做。这个时候就需要我们过度到中级层面来看待问题了

中级层

在这一层的理解我推荐看阮一峰的《理解RESTful架构》这一篇文章。我会综合其他几篇文章来谈谈自己的读后的理解。

首先对REST进行一个定义，从字面翻译来看是指“表现层状态转化”。这个字面意义初看我是无法理解的，只能进行拆解。

其中的R是指翻译成中文是指表示层。（但是我没有查到是否与OSI的7层模型中的表示层有什么区别，中文中这两个意思都一样，甚至在英文中两者意思也没有什么差异，同时在StackOverflow上面搜索发现和也是可以混用的）。在阮一峰看来，这里的表示层是指资源的表现层，在互联网上可以用一个URL（统一资源定位符）来指向它。

状态转化（State Transfer）：从《图解HTTP》中我们能得知HTTP协议是一种无状态的，排除Cookie，无法区分同一个URL请求的状态。如果想操作服务器，就必须通过某种方法，让服务器发生状态改变。这里指的其实就是HTTP的动词方法。，，，等都属于是常见的动词方法。

那么再有了上面的理论之后，我们得出结论是：1.每一个URL代表了一个资源，客户端和服务端通过HTTP中的动词方法来说明自己的意图。

例如简述的用户首页请求这种就是一个RESTful风格的URL，如果需要发送一些具体的信息可以使用这种形式在请求内容中附上具体信息就好。整个的path路径中不需要带上动词，因为HTTP的动词就已经能够很好的说明一切了。

最后服务端在做出响应的时候，只要配合上响应码code这时就能够确切的得知服务端的具体信息了。

初看好像这样的做法没什么，但是如果细细想一下就会发现，这样的架构设计不仅能用于web，也可以用于其他端，或者是任意一个支持了HTTP协议的工具。

这样的架构设计非常巧妙的把前后端进行了数据层面上的分离。在web开发进行前后端分离的时代，做出了很大的理论与架构设计上的贡献。这是我目前对REST架构设计的理解。

高级层

到了这一层，大部分优秀的经过别人的理解之后加工出来的文章你可能都已经看过了，那么接下来你需要去啃论文了。

如果只从第5章和第6章讲REST架构的地方开始看的话，大概是70多页的内容。初步计算需要花费4-5天的业余时间。理性告诉我现阶段我不该在这上面耗费太多时间。所以如果还有第三次学习REST的话，我会直接去学习原版论文。

总结

通过这次学习，对REST又有了一些深入的理解。虽然在我看来也只是再原来浅薄的基础上又深入了一些。

写在结尾，熟悉了REST，你知道最近有一个新的概念叫GraphQL么，与REST相比他又能算得上是一种新的思想。

技术总是在不断的变化，三年开发给我的最深的感触就是，恰恰是那些在大学计算机系里面经过了几十年沉淀下来的那些不变的基础知识才是最有用技能。而这个行业的很多新人在追寻的只不过是屠龙之技罢了。

参考资料

怎样用通俗语言解释REST，以及RESTful https://www.zhihu.com/question/28557115

理解RESTful架构http://www.ruanyifeng.com/blog/2011/09/restful.html

REST架构相关论文http://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf