最佳实践 - 由两个名称标识的资源的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
的子资源应该直接是某个证书(而不是像所有提供者那样的一组证书)。
你的第二个解决方案.../{id1}/{id2}
说,对我说,你有id1
和id2
之间的层级关系,这似乎是因为两个 标识引用相同的资源,就像你说的不修复得非常好你的资源的设计。在另一方面,你先解决.../{id1}-{id2}
可以使用;
代替-
避免暗示层次结构中没有这样的 在Restful Web Services引用,所以我会用这个去:
.../{id1};{id2}/
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原则:无状态。
你能详细说明2个名字的含义和这些ID代表什么吗?如果你提供一个例子来给出更多的上下文,那会更好。 – 2013-04-08 10:05:47
编辑我的第一篇文章。 – user1056903 2013-04-08 11:08:56
你可以更具体地说明你想要读取最后一个url的内容吗?如果不是提供者的所有证书? – Twissell 2013-04-08 11:16:12