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 回答