Question

如果我有资源/用户和资源/声明，/ claim / 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" }

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

最安静的事情是什么？谢谢！

Answer 1

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

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

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

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

与REST无关，我会将postingUserURI更改为author作为URI的字段名称。