我正在开发一个 RESTful api。现在我将请求分类为get 、 modify 和 action。
- 获取使用 GET
- 修改使用 POST、PUT、PATCH、DELETE
- 动作使用 OPTIONS
动作的一个例子是OPTIONS /dogs/:id/feed
,这将导致狗的状态改变流动服务器脚本中定义的逻辑。
那么,如果我将 OPTIONS 用于此用途,会有什么问题吗?
我正在开发一个 RESTful api。现在我将请求分类为get 、 modify 和 action。
动作的一个例子是OPTIONS /dogs/:id/feed
,这将导致狗的状态改变流动服务器脚本中定义的逻辑。
那么,如果我将 OPTIONS 用于此用途,会有什么问题吗?
可能存在问题,因为您正在滥用 OPTIONS。阅读 RFC 7231 的第 4.2.1 节(https://greenbytes.de/tech/webdav/rfc7231.html#rfc.section.4.2.1):
如果定义的语义本质上是只读的,则请求方法被认为是“安全的”;即,客户端不请求也不期望由于将安全方法应用于目标资源而导致源服务器上的任何状态更改。同样,合理使用安全方法预计不会对源服务器造成任何伤害、财产损失或异常负担。
...
在本规范定义的请求方法中,GET、HEAD、OPTIONS 和 TRACE 方法被定义为安全的。
操作的一个示例是 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)。您不应将其用于任何其他目的。