使用 HTTP 方法“选项”进行自定义使用？答案

【问题标题】：Use HTTP method 'OPTIONS' for custom usage?使用 HTTP 方法“选项”进行自定义使用？
【发布时间】：2017-08-25 03:15:06
【问题描述】：

我正在开发一个 RESTful api。现在我将请求分为获取、修改和操作。

get 使用 GET
修改使用 POST、PUT、PATCH、DELETE
action 使用 OPTIONS

一个动作示例是OPTIONS /dogs/:id/feed，这将导致狗的状态改变流向服务器脚本中定义的逻辑。

那么，如果我将 OPTIONS 用于这种用法，会有什么问题吗？

【问题讨论】：

如果你要做自己的事情，为什么要创建一个 RESTful API？遵循标准的目的是使集成变得容易。

标签： http restful-architecture api-design http-options-method

【解决方案1】：

一个操作示例是 OPTIONS /dogs/:id/feed，这将导致狗状态更改流向服务器脚本中定义的逻辑。

在这种情况下，为什么不使用POST？操作只是您创建/更新的东西的模型，因此您可以使用POST（或PUT，如果您知道将资源放在哪里）。

在这种情况下，我会这样做：

POST /dogs/:id/bowls
Content-Type: application/json
{
    "bowlContent" : <food description>
}

这将创建一个装有食物的碗（实际上是饲料的意思）。

OPTIONS 通常用于查询如何使用特定资源（意味着我的选择是什么？请参阅http://zacstewart.com/2012/04/14/http-options-method.html），或作为跨域 Ajax 调用中的预检请求（请参阅https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS）。您不应将其用于任何其他目的。

【讨论】：

【解决方案2】：

可能存在问题，因为您在滥用 OPTIONS。阅读 RFC 7231 (https://greenbytes.de/tech/webdav/rfc7231.html#rfc.section.4.2.1) 的第 4.2.1 节：

请求方法被认为是“安全的”，如果它们定义的语义是本质上是只读的；即，客户端没有请求，也没有期望，由于应用程序导致源服务器上的任何状态更改目标资源的安全方法。同样，合理使用保险箱方法预计不会造成任何伤害、财产损失或异常源服务器的负担。

...

在本规范定义的请求方法中，GET、HEAD、 OPTIONS 和 TRACE 方法被定义为安全的。

【讨论】：

如果我与客户有明确的协议怎么办？
你仍然违反了 HTTP 规范。
我不在乎我是否违反了某些东西，只要它没有伤害：)
好吧，它可能会以意想不到的方式失败。
是的，这就是我想在这里找到的：（