RESTful接口设计到底是什么？一篇搞懂它的核心思想！

开头讲讲，以前我那接口设计，真是没法看。简直就是一锅稀粥。

我刚开始搞后端的时候，写接口那叫一个随心所欲，爱咋写咋写。创建（就是增加）一个用户，我就叫它 /addUser。删除一个，叫它 /deleteUserById。改数据，/updateUserInfo。查列表就是 /getUserList。

搞了一堆动词在 URL 里头，每次自己想用，或者新来的同事要接手，都得翻代码确认到底写的是 addUser 还是 createUser，抑或是 postUser，头都大了。用久了，连自己都会搞混，完全没有一个统一的规矩。

第一次听说RESTful，一头雾水！

那阵子，听圈子里的人老是提什么 RESTful，说那是正经的、高大上的接口设计方式。我这人一根筋，心想：既然是好东西，那就得学！

我屁颠屁颠地就去搜了。结果一看，什么“无状态”、“统一接口”、“HATEOAS”，给我整得云里雾里。心想，这不就是把 URL 改得好看点吗？至于用这么多生僻词吗？当时完全没理解到它的核心，觉得这技术圈的人就是喜欢装高深。

试着按照书上说的去改了一点，效果不佳，还是习惯性地在 URL 里塞动词。那段时间的代码，说它是四不像都算是夸它了。直到我真正接手了一个对外开放的、需要跟多个前端团队合作的大项目，我才下定决心，必须得把这个 RESTful 啃下来，不然协作的沟通成本实在太高了。

我的土办法：抓住名词和动作！

后来我慢慢摸索，把那些洋气的、听不懂的概念都抛一边了，就抓住最核心的两点去实践，用我自己的土话说，就是 “一切皆资源”，“动作交给方法”。

我的实践过程，就是强制自己做了一次思想转换：

• 少用或不用动词在 URL 里头：我们的业务不就是围绕一些“东西”在转吗？比如用户、订单、商品，这些就是名词，也是我们说的“资源”。我把它们放到 URL 里，比如 /users、/orders。我的 URL 永远都只是一个名词的复数形式。
• 用 HTTP 自己的那几个动作（方法）来说明你要干以前在 URL 里写的动词，现在我都要求自己用 HTTP 方法来表达。

具体的实现就是：

• 想要创建用户， 我就用 POST 方法往 /users 这个地址提交数据。
• 想要获取用户列表， 我就用 GET 方法去请求 /users。
• 想要修改一个特定的用户， 我就用 PUT 或 PATCH 方法对着 /users/123 这个地址砸数据。
• 想要删除一个特定的用户， 我就用 DELETE 方法对着 /users/123 操作。

我还强行要求自己，别再一股脑地只返回 200 完了。我们得像个正经人一样，好好对待 HTTP 状态码。

• 创建成功？ 给个 201（Created）。
• 删除成功或者查到了？ 还是 200（OK）。
• 客户端传的数据有问题？ 扔个 400（Bad Request）回去。

以前我判断失败，全靠返回的 JSON 里的一个 code: -1。现在我们直接看 HTTP 头就知道个大概，后台联调的人看日志都清爽多了。这才是 RESTful 真正让我服气的地方，它让通信变得有礼貌、有规矩。

最终效果：舒服！能跑！

自从我把这个“资源导向”的思想贯彻下去之后，我那堆接口代码一下子就变得有章法了。大家看到一个新的接口，比如 /goods，不用再问我是用来增删改查哪个了，直接看他是用 GET 还是 POST 就知道要干嘛沟通成本一下就降下去了，大家写起代码来都很顺畅。

这个实践过程，说白了就是把复杂无序的东西，用一个行业里大家都懂的“规矩”给框了起来。我可以负责任地说，RESTful 的核心思想，就是这么简单粗暴！你也赶紧去动手改改你那堆 /doSomething 的接口！动手了才能真正搞懂它！