rest - REST 资源，它们应该是特定于客户端、特定于服务器还是两者兼而有之？

Question

我有一个用例，对于同一个实体，有 2 个标识符，如果单独使用，每个标识符都可以映射到实体。1 个标识符是客户端友好的（比如 c_id），另一个是服务器友好的（比如 s_id）。客户确实知道 s_id，但在大多数情况下他们不会使用它。并且服务器知道这两个 id，但是服务器上的实现使得每件事都可以使用 s_id 轻松映射。在这种情况下，在 c_id 和 s_id 级别提供资源是否是一种好习惯，其中资源名称和 id（在输入中）将不同并且会做同样的事情，或者它应该只是一个资源，这也引发争论应该使用哪种资源。

Answer 1

我经常做的是将规范的 URI 创建为带有 的 URI，s_id例如，

http://example.org/api/foo/{s_id} 

然后提供一个搜索工具，允许按c_id和可能的其他属性进行搜索。

http://examples.org/api/foos?c_id={c_id}

这可以返回一个 foo 列表，每个都带有一个指向s_idURI 的链接。或者，如果像您的情况一样，只有一个 foo 返回，那么您可以重定向到规范 URI，或者您可以实际返回完整的 foo 表示并将 Content-Location 标头设置为规范 URI。

Answer 2

您的 API 是为了用户的利益而存在的。您应该始终努力使他们尽可能轻松。如果所有资源都存在唯一的客户端友好 ID，则让您的 API 针对客户端友好 ID 工作。您的 API 可以在内存中存储从 clientId 到 serverId 的映射，并轻松切换到更适合的 ID。

如果所有资源都没有唯一的对客户友好的 ID，那么您就有了麻烦。我会首先尝试缩小差距（即提供剩余资源clientIds）。如果这不是一个选择，那么我同意达米恩的观点。

Answer 3

我通常会将资源存在于其服务器身份下，然后提供将 302 重定向（如果您愿意，也可以返回 307）返回到适当资源的搜索方法。客户端将使用这些搜索/查询方法来获得正确的资源。

因为服务器“拥有”资源（及其 URL），所以它可以通过 URL 摆弄来获得资源。然而，由于客户端不应该进行 URL 摆弄来查找资源，因此为他们提供了一个查询方法，他们可以在其中指定他们知道的 ID 作为查询字符串参数，这样感觉更清晰。