Question

我有一个用例，对于同一个实体，有2个标识符，如果单独使用，它们中的每一个都可以映射到实体。 1个标识符是客户端友好的（比如c_id），另一个是服务器友好的（比如s_id）。客户端确实知道s_id，但在大多数情况下他们不会使用它。并且服务器知道这两个ID，但是服务器上的实现是这样的，即使用s_id可以很容易地映射每个东西。在这种情况下，在c_id和cnid上提供资源是一种好的做法。 s_id级别，其中资源名称和id（在输入中）将不同并将执行相同的操作，或者它应该只是单个资源，这也导致争论应该使用哪个资源。

Answer 1

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

因为服务器“拥有”资源（及其URL），所以可以通过URL -fiddling来获取资源。然而，因为客户端不应该使用URL-fiddling来查找资源，给他们一个查询方法，他们可以指定他们知道的ID，因为查询字符串参数感觉更清晰。

Answer 2

您的API的存在是为了用户的利益。你应该始终努力使它们尽可能简单。如果所有资源都存在唯一的客户友好ID，则使您的API与客户友好ID相对应。您的API可以在内存中存储从clientId到serverId的地图，并轻松切换到更舒适的ID。

如果所有资源都没有唯一的客户友好ID，那么你就有了一个泡菜。我首先尝试缩小差距（即给剩下的资源clientIds）。如果那不是一个选择，那么我同意Damien。

Answer 3

我经常做的是将规范URI创建为s_id的URI，所以像

一样

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

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

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

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

REST资源，它们应该是客户端特定的，服务器特定的还是两者兼有

3 个答案: