我有独特的 RESTful 资源，只能在系统中用两个属性来识别。 我想知道的是执行此操作的最佳实践方法是什么。
资源由 id 属性（不是唯一的）和 name 属性（也不是唯一的）标识，但是这两个属性的组合是唯一的。
目前我们的 URI 看起来像这样，但这似乎不对：
http://www.domain.com/somepath/myresource?firstid=1&secondid=aname
我在想将两个属性（例如“firstid-aname”）结合起来会更好，因为这似乎描述了资源的永久性。例如这样你就可以得到一个 URI：
http://www.domain.com/somepath/myresource/firstid-aname
或者做这样的事情会更好吗，我在其他地方看到过：
http://www.domain.com/somepath/myresource;firstid=1;secondid=aname
任何建议将不胜感激。 谢谢
【问题讨论】：
我认为你的第一个例子还不错。由于各种非字母数字字符，可能有些人认为它不是很干净。很多时候你会看到这样的东西：
http://www.domain.com/somepath/myresource/firstid/1/secondid/aname
但是，由于 REST 是一种架构而非标准，因此您可以随心所欲地进行操作。我个人认为 URI 不一定要非常漂亮。
edit 在有人抱怨之前：当然，如果他们是的话，那也不错。大多数时候，它们是由不关心的程序读取和发出的。漂亮的 URI 更适合调试。
【讨论】：
对于RESTx，我们允许在 URL 中定义“位置参数”。所以，你可以这样写：
http://www.domain.com/somepath/myresource/1/aname
但您始终可以选择在 URL 中指定普通查询参数，如下所示：
http://www.domain.com/somepath/myresource?firstid=1&secondid=aname
哪个选项最适合您可能取决于您编写的客户端应用程序的类型。例如，RESTx 不会强制您使用其中之一，您可以同时使用它们。
但请考虑一下：一些网络缓存和其他“智能”网络基础设施元素在 URL 中的参数存在问题。他们可能会忽略路径结束后的所有内容（例如查询参数），因此您的 RESTful 资源不会被缓存或以其他方式正确处理。这在较小的组织中可能不是问题，但如果您的 RESTful 资源暴露在 Internet 上，您可能需要考虑这一点。
我喜欢遵循 URL 路径应该标识资源本身的原则，而任何参数仅用于修改这一请求的输出。当然，如果您始终使用相同的查询参数，那么您不妨允许它们作为 URL 中的位置参数。
【讨论】：