通过代理 ID 或业务 ID 获取资源的 REST 方法
我们有一些实体既有唯一的业务 ID（例如“my-unique-name”），也有内部 UUID（例如 aa54-342-dffdf-55445-effab）。 Whats 是提供可以使用任一方法返回资源的 REST URI 的好方法。
方法 1 - 有两个资源 URL（丑陋！！！）：
/foo-by-id/我的唯一名称
/foo-by-uuid/aa54-342-dffdf-55445-effab
方法 2 - 始终使用查询参数（即使它返回单个项目......似乎不-休息类）
/foo?id=我的唯一名称
/foo?uuid=aa54-342-dffdf-55445-effab
方法 3 - 让 Web 服务确定 {id} 是否是 UUID（这可能容易出错，但无论如何，都可以正常工作...
方法 4 - 使用 UUID，允许业务 id 作为查询参数（不知道这是否可行）
/foo?id=我的唯一名称
/foo/aa54-342-dffdf-55445-effab
任何想法表示赞赏。
We have some entities that have both a unique business id (e.g. "my-unique-name") and also have an internal UUID (e.g. aa54-342-dffdf-55445-effab). Whats is a good way to provide a REST URI that can return the resource using either method.
Approach 1 - have two resource URLs (ugly!!!):
/foo-by-id/my-unique-name
/foo-by-uuid/aa54-342-dffdf-55445-effab
Approach 2 - always use a query parameter (even though it returns a single item...seems un-rest-lke)
/foo?id=my-unique-name
/foo?uuid=aa54-342-dffdf-55445-effab
Approach 3 - have the web service figure out whether the {id} is a UUID or not (this could get error prone, but in all likihood would work just fine...
Approach 4 - use the UUID, allow business id as a query parameter (don't know if this would work)
/foo?id=my-unique-name
/foo/aa54-342-dffdf-55445-effab
Any thoughts are appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我将使用类似于选项 4 的内容。使用路径段中的 UUID 作为单个资源 URL。使用备用 URL 作为一种搜索 URL，
例如
您不希望两个 URL 都返回具有相同资源的 200。这会导致缓存污染。
现在您可以自由地使用 GET“搜索样式”URL 进行其他类型的搜索。
或者你甚至可以搜索不独特的东西。
I would use something similar to option 4. Use the UUID in the path segment as the single resource URL. Use the alternate URL as a kind of search URL
e.g.
You don't want to have two URLs that both return a 200 with the same resource. That causes cache pollution.
And now you are free to use the GET "search style" URL for other types of searches.
or you could even search on non-unique stuff.
选择一个作为规范，然后 307 将另一个重定向到它。如果不这样做，那么您将面临两个 URI 返回不同数据的风险，因为它们在不同的时间或生命周期被缓存。通过从一个重定向到另一个，您可以允许 PUT、POST 或 DELETE 请求使单个规范 URI 的缓存失效。使用 307 而不是 302，这样“历史”客户端就不会将 POST 更改为 GET。我推荐方法 1，将 UUID 重定向到企业 ID，因为它更漂亮。
Pick one as canonical, and 307 redirect the other to it. If you don't, then you run the risk of the two URI's returning different data because they have been cached at different times or lifetimes. By redirecting from one to the other, you allow a PUT, POST, or DELETE request to invalidate the cache of a single, canonical URI. Use 307 instead of 302 so that "historic" clients don't change POST to GET. I'd recommend Approach 1, having the UUID redirect to the business ID just because it's prettier.
REST 并不全是关于漂亮的 URL。然而，在我看来，第一种方法并不是真正的 REST，因为正如您指出的那样，有两个“资源”。
第二种方法是 REST，但如果你不想有 QS 风格的 URL，你可以这样做：
然后你可以使用正则表达式来分割它。
就我而言，我喜欢最后一个，因为 URL 很好。
REST is not all about nice URL's. However the first approach is, in my own opinion, not really REST because of the two "resources" as you pointed out.
The second approach is REST, but if you don't want to have a QS style URL, you can do something like this:
Then you can split it by using a regex.
As far as I'm concerned, I like the last one because of the nice URL.
我会采用第二种方法。 Moslty 是因为从语义上讲，您希望通过某些内容“过滤”来获取名为 foo 的实体。
这显然是通过对其属性（即 id 或 uuid）定义约束来体现的。
也就是说，REST 与 URL 无关。您所谈论的方法通常称为“nice urls”。 REST 是关于通过常见操作（HTTP 方法）和名称（URL）执行的资源表示的语义驱动操作。
您可以在 Fielding 论文上阅读有关 REST 的更多内容。
此外，如果您想实现 RESTful，则每个实体都应该具有唯一的 URL。但正如菲尔丁本人指出的那样，没有人是安宁的。
I would go with the second approach. Moslty because semantically speaking, you want to GET entity named foo by "filtering" through something.
This something is obviously reflected by defining constraints on its attributes, namely id or uuid.
That said, REST is not about URLs. The approach you are talking about is commonly known as "nice urls". REST is about semantically driven operations on representation of resources carried out by common actions (HTTP methods) and names (URLs).
You may read something more on Fielding dissertation about REST.
Moreover, if you want to be RESTful, you should have unique URLs for each entity. But as Fielding himself points out, nobody is RESTful.
我目前正在开发带有休息通话的Android应用程序，我使用了第二种方法，
原因是其余唯一路径 id 更适合人类可读的格式
例如 http://example.com/rest/news/2007/6 显然是代表 2007 年第 6 个月的新闻。
I'm currently developing android app with rest calls and i used second approach,
the reason is rest unique path id is more comfortable with human readable format
such as http://example.com/rest/news/2007/6 is obviously represents news in year 2007 and month 6.
根据 REST 原则，每个表示都应该有一个唯一的 URI。
具有业务密钥的实体可能也通过业务密钥引用相关实体，因此这种表示方式与具有 UUID 的实体不同，后者可能会使用 UUID 来表示其相关实体。
According to REST principles, each representation should have a unique URI.
The one with the business key probably refer to related entities by business key as well, so that representation is different from the one with the UUID, which will use probably UUID's for its related entities.