最佳实践 - 由两个名称标识的资源的REST URI设计

REST资源应由两个名称标识。最佳做法是什么？最佳实践 - 由两个名称标识的资源的REST URI设计

我的想法：

.../{id1}-{id2} 
.../{id1}/{id2}

一个ID可以由数字，字母和特殊字符。

第一溶液：

如果ID中的一个包含字符-出现问题。在这种情况下，分隔字符不是唯一的。

解决方法二：

在刚刚.../{id1}就没有资源，这是REST风格的？

编辑：

的REST资源表示凭据。凭证由提供者名称和用户名标识。

.../Credentials/<ProviderName>;<UserName>

我不想在.../Credentials/<ProviderName>显示供应商的所有凭证（它不会适合我的XML结构）。

编辑2：

在.../Credentials所有凭据将在XML显示。凭证是以XML根元素的子元素表示的。我想创建一个与XML结构相同的REST资源结构。因此，.../Credentials的子资源应该直接是某个证书（而不是像所有提供者那样的一组证书）。

来源

2013-04-08 user1056903

你能详细说明2个名字的含义和这些ID代表什么吗？如果你提供一个例子来给出更多的上下文，那会更好。 – 2013-04-08 10:05:47

编辑我的第一篇文章。 – user1056903 2013-04-08 11:08:56

你可以更具体地说明你想要读取最后一个url的内容吗？如果不是提供者的所有证书？ – Twissell 2013-04-08 11:16:12

你的第二个解决方案.../{id1}/{id2}说，对我说，你有id1和id2之间的层级关系，这似乎是因为两个标识引用相同的资源，就像你说的不修复得非常好你的资源的设计。在另一方面，你先解决.../{id1}-{id2}可以使用;代替-避免暗示层次结构中没有这样的在Restful Web Services引用，所以我会用这个去：

.../{id1};{id2}/

来源

2013-04-08 09:48:57 Twissell

Annotation @Path（“{id1}; {id2}”）似乎不适用于Jersey。 – user1056903 2013-04-08 11:39:33

REST API必须是超文本驱动，所以不要浪费你的时间在URL模式上，因为它们不是RESTful。 URL模式暗示着客户端和服务器之间的紧密耦合;简而言之，客户端必须了解URL的外观以及构建它们的能力。

也看到这个职位：

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

注意有关凭证;看起来你保持了客户端和服务器之间的状态，这也违反了REST原则：无状态。

来源

2013-04-08 15:55:13 filip26

最佳实践 - 由两个名称标识的资源的REST URI设计

回答

相关问题