分布式 (四) --------- 前后端完全分离与 Rest 规范

谁践踏了优雅 2024-04-01 09:36 47阅读 0赞

#### 目录 ####

*  一、概述
 *  二、解决

--------------------

## 一、概述 ##

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

这句话怎么说呢？如果说你要删除一个数据，以往的做法通常是 delete/\{id\}，如果你要更新一个数据，可能是 Post，数据放 Body，然后方法是 `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/{room_id}` 这样的东西，举个栗子,`/room/3242` 这就表示3242号房间。

这是一个清爽的世界啊，你想想，之前的Url是什么都要，我开房，可能是 `/open/room/3242` 我要退房可能 是`/exit/3242/room`，我要打理房间，可能是`room/3242?method=clean`。够了！这些乱七八糟的东西全够了，让世界回归清爽的本质，一间房，就是 `/room/3242` 没有别的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，而不是后端去渲染模板，从而实现前后端的完全分离。