这是一个创建于 2839 天前的主题，其中的信息可能已经有所发展或是发生改变。
不少程序员都是这么认为的，基于 HTTP API 的服务，只要用 GET 请求和 POST 请求就足够了。 像 RESTful 这样的 大量使用 PUT ， DELETE 请求是不必要的。
真的吗，我来举一个例子。
假设有一类资源 ResourceXYZ ，对其有增删查改的操作。 如果只使用 GET POST 之类的设计方式，那么很可能会设计以下的请求接口：
POST .../addResourceXYZ
POST .../delResourceXYZ
GET .../getResourceXYZ?resourceId=resourceId
POST .../updateResourceXYZ
如果按照 RESTful 的 设计方式，很可能会设计以下的请求接口
POST .../ResourceXYZs
DELETE .../ResourceXYZ/{resourceId}
GET .../ResourceXYZ/{resourceId}
PUT .../ResourceXYZ/{resourceId}
现在假设，客户端要获取该资源，其 ID 为 resourceId 。 如果成功，那么一切都好说。 如果失败， Restful 的处理方式是，通过 HTTP status 返回错误码来表示原因，例如 404 表示该资源不存在。
那么只用 GET POST 两种方法的方式呢？ 响应请求
GET .../getResourceXYZ?resourceId=resourceId
的时候能不能也用 404 呢？
按照 404 的语义，响应 404 是不对的： 因为客户端请求的 URL 实际上是正确的，只是对应的参数没有找到对应的结果 很多时候，就只能靠响应 200 然后返回空数据或者空对象来处理了。 例如 Content-type 为 application/json 时，可以返回 {} 或者
{
"error": "not found",
"code": 404
}
这样就会要求客户端，必须处理 HTTP 回复的具体内容，而不能只处理头部。 那么客户端要怎么处理这个 json 呢 要先解析 json ，然后尝试分别这是一个资源的内容，还是一个错误提示。
对于强类型语言例如 C/C++ OC Swift 写的客户端来说，恐怕就忍不住要问候服务端程序员一家了。
更重要的是……
没有库会支持这种拍脑袋式的设计。
全文完，欢迎拍砖。
207 条回复 • 2018-09-01 23:44:06 +08:00
 |
201
noli OP @Balthild 只是你读的大学以及其同类必修马列毛邓好吗。这世界上又不是只有必修马列毛邓的大学。
你首先给 REST 树了一个不存在的靶子让自己 YY 开火： REST 本来就只是在基于请求答复、基于 HTTP 的模型上有优势。我从来没有说过 REST 能解决任何的问题，而你也没有描述一个 REST 预期可以解决的问题。 我一直在说，这么高的楼层里面讨论过的，大多数人所实践的做法，不是不 work ，而是 REST 在这些问题上可以解决得更好：好处在与，如果系统规模扩张后， REST 的做法有助于保持低耦合高开发效率，而不是说这些做法在其所在实践环境中效率不够。 鬼知道你理解成什么东西了，什么全称命题、任意场。 |
 |
202
Balthild 2017-04-21 20:18:18 +08:00
@noli
1. 必修马哲是国家政策规定的好不，除非你不是国内读的大学。鉴于你没有强调，我默认你是国内读的。 2. 你难道不是自己说过，没有什么是抽象不成资源来给 REST 解决的吗？ 3. 我一直说的就是「而是 REST 在这些问题上可以解决得更好」这一个命题不一定成立，要看具体场合。 4. 已经说过了，是「任意场合」打少了一个字。至于全称命题，类似「所有 XXX 都 YYY 」就是全称命题，这算高中水平的知识。 |
 |
203
aaronlam 2018-03-09 00:50:35 +08:00
突然看到一个别人的一个问题，想了想好像的确是他所说那样，不知楼主怎么看这个问题呢？谢谢！
大神，我一直存在一个问题就是 http 协议的几个动词是不是够用？因为你上面提到了说 get post update delete 是几个数据的元操作，那么请问如何执行比较复杂的操作呢？因为 mvc 开发模式中比较重要的 controller 都是用动作 action 来驱动的。比如我需要实现两个数相加，按照本能设计的 url 就是 ../add/num1/num2，这样就出现了动词了，这是违反原则的 |
|
204
noli OP @aaronlam #203
可以参考栈式虚拟机的设计思想，将一系列的运算指令（运算 API 调用）视作往计算堆栈上 push 一个 op。 于是，调用某个 API 可以在 RESTful 中这样表示： 1. 操作资源是某个特定的堆栈 2. POST 一个 Op， 例如 add， 其实现就是，在堆栈上读取(Pop)一个现存数据作为 add 的一个操作数，以及 从 post 请求中得到的 另一个 操作数。 |
 |
205
ybark 2018-09-01 13:09:54 +08:00
上面一大堆撕 b 回复，看了以后很客观的觉得是浪费时间。我想，作为一个正常的靠谱开发者，对 restful 不可能不产生一种排斥和别扭的感受。个人觉得以资源为中心组织 url 很受用，但是非要让业务逻辑去依赖 http 协议中的语义我 tmd 就是不爽（包括 http method 以及 status code ）。
这里有一篇文章为我这种不爽提供了很靠谱的解释和出口： https://eggggger.xyz/2017/01/04/restful-api/ 。 无意争辩和钻牛角尖，我认为开发者的心态大概应该这样： 透彻的理解你的问题，然后用你熟悉的技术和方法解决问题赚钱； 如果在解决问题时发现你正在用的技术和方法不熟，那就继续搞明白，如果觉得不爽，就用你认为正确的技术和方法继续解决问题并赚钱。 在解决问题并赚钱的这个大目标上，用还是不用 restful 基本上没什么太大的决定性影响。 |
|
206
ybark 2018-09-01 13:16:42 +08:00
觉得时间太特么多的也可以看看“ RESTful APIs, the big lie ”原文的撕 b： https://mmikowski.github.io/the_lie/
|
Select Language