面试专题：前后端分离与 Rest 规范

http 是目前互联网上使用最多的协议，没有之一。可以是 http 的创始人一直都觉得，在过去 10 几年来，所有的人都在错误的使用 Http。

这句话怎么说呢？如果说你要删除一个数据，以往的做法通常是 delete/{id}，如果你要更新一个数据，可能是 Post 数据放 Body，然后方法 Url 是 update/{id}，或者是 artichle/{id}?method=update。

这种做法让我很暴躁，我觉得这个世界不该这样的，所有的人都在误解而且在严重错误的误解 Http 的设计初衷，好比是发明了火药却只用它来做烟花爆竹。

那么正确的使用方式是什么呢？如果你要看 Rest 各种特性，你恐怕真的很难理解 Rest，但是如果你看错误的使用 http 的人到底犯了哪些错，什么是 Rest 就特别容易理解了。

**第一条，混乱。**一万个人心里有一万个 URL 的命名规则，URL 是统一资源定位符，重点是资源。而很多人却把它当成了万金油，每一个独立的虚拟的网页都可以随意使用，各种操作都能够叠加。这是混乱的来源之一。

**第二条，贪婪。**有状态和无状态全部混在一起。特别是在购物车或者是登陆的应用中，经常刷新就丢失带来的用户体验简直不要不要的。每一个请求并不能单独的响应一些功能，很多的功能混杂在一起里。这是人性贪婪的本质，也是各种 Hack 的起源，只要能够把问题解决掉，总会有人用他认为最方便的方式去解决问题，比如说汽车门把手坏掉了直接系绳子当把手，emmmm这样确实很棒啊。

**第三条，无序。**返回的结果往往是很随意，各种错误信息本来就是用 Http 的状态码构成的，可是很多人还是喜欢把错误信息返回在返回值中。最常见的就是 Code 和 Message，当然对于这一点，我个人是保留疑问的，我的观点是，Http 本身的错误和服务器的内部错误还是需要在不同德层面分开的，不能混在一起。可是在大神眼里并非如此，这个再议。

**那么怎么解决这些问题呢？强迫症患者的福音就是先颁发规则，第一个规则就是明确 Url 是什么，该怎么用。就是所有 Url 本质来讲，都应该是一种资源。一个独立的 Url 地址，就是对应一个独一无二的资源。**一个冰淇凌，一位老师，一间房子，在 Url 上对应的都是一个资源，不会有多余的 Url 跟他对应，也不会表示有多个 Url 地址~~注意，这里指的是 Url 地址，并不是单独的参数，他就是一个 /room/{roomId} 这样的东西，举个栗子，/room/233 这就表示 233号房间。

这是一个多么清爽的世界啊，你想想，之前的 Url 是什么都想要，开房——就是 /open/room/233 ，退房——就是 /exit/233/room，清理房间——就是 room/233?method=clean。
够了！这些乱七八糟的东西全够了，让世界回归清爽的本质，一间房，就是 /room/233 没有别的 Url 地址了。那我想要对这个资源操作怎么办？这就是棒棒哒大神想出来的了，http 有几种 Method来着？get，put，post，delete，还有其它隐藏的4种。在过去的混乱世界里，经常用的就是 Get 和 Post。如果不是因为 Get不支持大数据传输，我想连 Post 都不会有人使用。（想象一下 Roy Fielding 在愤怒的对着电脑屏幕喊，Http 的 Method 一共有八个，你们为毛只逮着 Get 一只羊的毛薅薅薅薅薅）。

而对资源最常见的操作是什么？CRUD，对不对，就是创建，读，更新，删除。再看 Http 的 Method？是不是非常完美？其实也怪 Fielding 老爷子一开始命名不准确，如果刚开始就是把 Get 方法叫做 Read，Put 方法叫做 Update， Post方法叫做 Create 这该多好……

你用一个 Get，大家又发现没什么限制没什么所谓，又很难了理解 Put 和 Post 的差别，法无禁止即可为啊，呃，老爷子不要瞪我，我瞎说的。

总之，这四种方法够不够你浪？你有本身找出来更多的对资源的操作来啊，我还有 4 个 Method 没用过呢。如果这 4 个真的不够了，有什么问题，大不了我再重新更改 http 协议啊。
其实简单说，对于 Rest 理解到这里就够了。后续的东西，都是在这一条基础上空想出来的，比强迫症更强迫症，当然，无状态我是百分百支持的。以上的各种表述可能不太准确，也纯属是我的意淫和各种小道资料，并未考据，但是凭良心讲，我是早就看不惯黑暗年代里的 Url 命名风格了，所以当最早接触到 Rest 的时候，瞬间就找到了真爱，我靠，这不就是我一直想要的答案吗？

但是我一直想的仅仅是命名规范，从来没有把自己的思考角度放在一个 Url 就是一个资源，所有的操作都是对资源的更改而言的角度上啊。所以你能理解的程度，更多的就是在于你要弄清楚你要解决什么问题，如果你的问题只是理解 Rest，恐怕你很难理解，如果你的问题是怎么解决 Url 混乱的问题，你反而很快能弄懂了~

Rest操作最佳实践：现在很多企业中，虽然都在支持 Rest 规范，但是真正严格最受的几乎没有，因为按照 Rest 规范，删除需要发送 Delete 请求，插入需要发送 Put 请求，过于繁琐，并且有些框架，例如 ajax，SpringMVC 等，对 Delete 和 Put请求的支持不太友好，所以实际应用中很少使用这两种请求，一般还是只是 Get 和 Post 请求，使用接口名字来区分，所以，对于 Rest 规范，只需要记得传输数据只使用 JSON，而不是后端去渲染模板，从而实现前后端的完全分离。