8

我很想了解更多关于 PUT 调用的 RESTful 设计模式。具体来说，我在 PUT 调用中更改资源 ID 是否违反了规范？

考虑以下...

POST /api/event/  { ... } - returns the resource ID (eventid) of the new event in the body
GET  /api/event/eventid
PUT  /api/event/eventid   - returns the (possibly new) resource ID depending on request body
GET  /api/event/eventid   - fails if the original eventid was used in the URI

如果 eventid 表示内部资源（如数据库记录），则 GET 和 PUT 的端点可以快速访问资源。如果 PUT 导致服务器移动底层资源，则 ID 可能会更改。

我这样做是否违反了规范？

4

3 回答 3

6

REST 不是一个严格的规范，而是一组可以遵循的准则和最佳实践来构建易于理解和使用的 Web 服务。因此，没有什么可以阻止您在 PUT 期间更改资源 ID。

话虽这么说，这样做是 IMO 一种不好的做法。REST 背后的想法之一是可以使用URI引用每个资源。在您的情况下，此 URI 是路径和（我假设）内部 ID 的串联。此 URI 可以被其他“系统”使用并存储为引用。如果更改 PUT 上资源的 ID，则更改 URI 并且对该资源的所有引用都将被破坏 (404)。

如果您觉得需要更改作为 URI 一部分的 ID，那么您可能没有为它选择正确的属性。考虑其他不可变的东西（例如：用UUID标记您的资源并使用它而不是内部数据库 ID）。

于 2012-11-07T03:08:28.840 回答
1

没有完全解决您的问题，但这让我担心：

返回正文中新事件的资源 ID（eventid）

您没有返回整数 id，然后让客户端从中构造 url，是吗？一个适当的 REST 应用程序应该为资源提供 url，而不是 id。

至于你的问题 - PUT 的意思是“在这个位置创建一个新资源”。可以想象，您可以使用重定向和Location标题进行回复，但这有点奇怪。此外，PUT 的语义要求您随请求一起发送整个实体，这可能不是您在这种情况下想要的。也许在这种情况下使用 POST 会更合适？（例如 POST on/api/event/1234

于 2012-06-18T21:15:45.753 回答
1

我觉得还可以；PUT 仍然是幂等的（重复调用不会导致其他修改）。

只是：我会确保不重复使用旧 ID，并让 api 返回 301 代码以调用旧 ID（以防其他客户端具有资源链接）。

也许修改 ID 的初始 PUT 应该返回指向新资源位置的 303 代码，我在这里不确定。

于 2012-06-19T09:49:38.377 回答