为 URI 上的 PUT 发送所有数据是否正确的 REST 设计？答案

【问题标题】：Is it proper REST design to send all data for a PUT on the URI?为 URI 上的 PUT 发送所有数据是否正确的 REST 设计？
【发布时间】：2015-05-23 02:39:41
【问题描述】：

如果我有非常简单的数据要发送到服务器，是否可以设置一个 URI 方案，其中所有数据都可以在 URI 上而不是在正文中发送？例如，假设我正在设置用户首选项。我设想这样的事情：

PUT
/preferences/{setting-name}/{setting-value}

这使我的客户端代码非常简单，因为我可以将整个消息放在 URI 中。可以吗？或者我应该做更多类似的事情：

PUT
/preferences/{setting-name}

...内容中的价值？谢谢！

【问题讨论】：

标签： rest uri put

【解决方案1】：

您的第一个 URI 暗示有一个（子）资源位于

/preferences/{setting-name}/{setting-value}

但没有资源，只有价值。使用这样的 URI不是 RESTful，因为它不寻址资源。

您的第二个 URI 稍微好一些，因为它寻址的是 preferences 资源的子资源 {setting-name}。

但我更喜欢第三种方法：

POST /preferences
Content-Type: application/json

{
  "setting-name": "setting-value",
}

提出一种偏好。注意POST 的用法，而不是PUT。 PUT 通常被解释为在请求正文中包含资源的完整表示。此类请求应覆盖所有设置。使用POST 通常被解释为仅覆盖正文中指定的设置。其他设置应保持不变。

注意：

让我好奇的是你的 URI 的前面。真的只有一组偏好吗？所有客户端可以并且应该访问相同的首选项集吗？例如，如果首选项是基于用户的，则应使用 URI，如

/user/{user-id}/preferences/{setting-name}

访问用户{user-id}的{setting-name}首选项值。

【讨论】：

非常感谢您的回复！这很有意义。关于 URI，我的想法是我所有的 API 调用都发生在特定用户的上下文中，所以我认为没有必要每次都明确地命名用户。那不是犹太洁食吗？
“在上下文中”是什么意思？用户是如何指定的？
通过提供来自先前完成的身份验证握手的令牌来识别用户。该令牌可以通过标头或 cookie 呈现，但它必须在请求中，否则服务器将以未经授权的方式回复。此 api 没有在特定用户的上下文之外有意义的使用模式。