0

如果我有一个资源 /users 和一个资源 /claims，那么 /claims/7 会返回这个：

{ id: 7, text: "hello", postingUserID: 9 }

可以吗？或者应该是

{ id: 7, text: "hello", postingUserURI: "/users/9" }

我想后者更安静，但这很不方便，因为如果我想用 ID 做任何其他事情，我必须解析出 9。

或者我应该两者兼得？

{ id: 7, text: "hello", postingUserID: 9, postingUserURI: "/users/9" }

我喜欢这个，但它也有点多余。

做什么事情最安心？谢谢！

4

1 回答 1

1

最 RESTful 的做法是包含 URI。第一个选项对 RESTful 客户端不是很有用，因为它代表了死胡同。Web 浏览器是一个很好的 restful 客户端示例：选项 1 就像提供一个没有超链接的网页。用户无法推进应用程序状态（浏览器选项卡），他们只能阅读页面，然后按下后退按钮。

我推荐选项 2。客户端应该不需要 ID，因为它们只能用于使用 URI 模板生成的 RPC 样式的 HTTP 请求之类的东西。这表示不是 REST 的带外信息。ID 是不需要公开的内部实现细节。您甚至不需要包含声明对象的 ID。您当前在客户端中使用 ID 的任何内容都应该使用从上一个请求中收到的超链接。

例如，我自己的 API 有一个“作业编号”，这个编号是一个没有字母部分的整数。我在我的数据库中使用一个自动递增的 ID 字段来生成和保存这些工作编号，但是在将它们呈现给客户时，我将其显示为“工作编号”而不是数据库 ID。客户端不使用它来生成任何未来的请求，仅用于人类可读的显示。

在开发新的 API 时，您可能会发现输出看起来像 JSON 响应的 HTML 页面很有用。然后使用网络浏览器浏览它。每个 GET 请求都应该通过单击超链接（锚元素）而不是通过在 URL 栏中键入 ID 来生成。这种技术被称为API Surfing。

与 REST 无关，我将更改为postingUserURIURIauthor的字段名称。

于 2013-01-09T09:10:16.170 回答