我所理解的restful风格

   第一次看到时，看几个例子，心想这个风格很好理解，貌似是蛮简单的规范嘛。最近又看到几篇文件，对restful有了更深的理解。感觉网上很多帖子都是比较雷同的，只能知其然，而不知其所以然，更不知道来龙去脉，所以不能很好的应用或者弃用、甚至发展一个技术。

   没有时间找全各种资料来总结，目前只能凭一些资源中的线索，大概猜测一下这些问题，给自己一个回答。

   当我们做一件事情时，最主要提是动词+名词。比如获取一本书，买一件衣服，查看一批鞋子...扔掉购物袋。所以我们一系列的工作就是一系列的动词+名词。

1.为什么会设计出http这样的协议
   当出现互联网时，最主要的是面对各种各样的足够细小的名词，比如文本、图片、声音、视频，把一切这样细小而明确的东西组合在一起。相对来说，名词的个数是非常多的，而相对动词却比较少。

   而且显而易见的是，对这些工作分类时，首先是按物品分类，不会按动作分类。我们的世界是按资源组织起来的，因为图片会归一个机构管理，而没有机构管理获取这个动作。

   所以http协议面对的是细节的资源，必须以名词为主。因为资源划分的足够细小，所以动词就相对就非常的少了。

2.http是一个应用协议，而非传输协议
   传输协议只是传递消息，信息。而应用协议就实际具体的操作应用了，所以http会设计用url显示资源，用method指明操作，所以足够用这样的协议来实现应用了。
   而在当前实践中，由于浏览器的方便而引爆了web应用，所以把http当成一个传输参数的工具了，我们并不按照原来的http设计思路，而只是把参数传过来，至于做什么事情，由参数来决定。比如可以用get传的参数做任务你相做的操作，可是更改数据，可以删除数据，可以更新数据。有时只是考虑安全或者参数的大小。
   由于开发者对http的设计意图有误解，导致了将http这个应用层协议当成传输协议这样低效率的误用。

3.为什么传统的应用并没有引爆restful风格
    http应用协议就是从广阔的互联网来考虑的，而实际的应用却只是从monolithic这样的单体应用开始的，也许开始都是一台机器上，也许后面只是数据库拆分出去了。
   
    由于这些应用的复杂度与拆分的广阔度都没达到一定的程度，所以没有到达按最小的资源设计应用的时刻，直到现在SOA，微服务拆分到一定的细颗粒度，都有可能考虑到与http的初衷结合在一起了。

    在传统应用中，也会有一个名词，而通常这个名词只是大的模块划分，并没有细化的一个资源。比如url中出现order，这个并不是一个基础的订单对象，而是一个大的订单模块，所以对模块的工作，就有了createOrder这样的动词操作。这个动词有时不是只产生一个订单中的一个数据这么简单，可能代表着生成订单及子订单，甚至尝试去扣费，记录消费。是一个不折不扣的组合出来的大动作。这么想来，这样的设计也是名词+动词的设计，只不是是大颗粒度的模块名称与一系列繁多的操作的关系。
    由于这样的情况下的应用，以模块划分的名词并不是很多，而丰富的是动词。毕竟模块远小于模块内的各种操作。http恰好是多名称与少操作的组合，所以难以以http那样细颗粒度的应用协议相互匹配。自然把http当成传输协议来使用。

4.微服务的到来与restful的兴起
    随着软件系统的越来越复杂，应用不断的拆分，以及在互联网环境中的分布式应用的兴起，软件的设计与http协议风格可以有统一的基础了。
    如果你的应用中的名词拆到可以只用http提供的几个动作就可以使用了，那基本上拆到位了，可以用restful风格了。否则也只是学学样子而已吧。

5.不得不说的返回值设计
   http作为应用层协议，既然已经用了restful风格了，那么返回值也应该遵守这样的风格，有比如：status 200（成功）、500（内部服务器错误）这样的设计。
   另提到一点，这个返回码的设计对普通的返回码设计非常有学习价值。首先是分类，100、200...500这样的大分类，另外是404这样的细分类设计。
   比如我看到有的系统设计返回码，参数检测多一项不合格，就设计一个全新的返回码，没有归类，这样调用方会非常不方便，有时候调用方只想对所有的参数检测不通过情况，显示一个通用的通知，没有规律就要要每次有新情况而改代码，加上一种if判断。而有了归类的话，即使有新的，调用方通常也可以不改变代码。