urn在RESTful服务的URL中构建url路径

问题描述:

我们正在创建一个RESTFul服务,并试图确定URL路径格式。urn在RESTful服务的URL中构建url路径

我们有用于唯一标识整个组织中的资源,我们正在构建Rest服务以通过http内容协商以请求者正在查找的格式来服务该资源。

我的问题是,我们应该如何形成服务的URL的路径,哪一个更有意义。

http://{domain}/{somethinghere}/{full urn string} 
or 
http://{domain}/{somethinghere}/{urn-part-1}/{urn-part-2}/{urn-part-3} 

我也有同样的问题呢!......恕我直言,我会用满瓮串,

http://{domain}/{somethinghere}/{full urn string} 

它的优雅,半合法的,并具有使一个用户友好的功能您可以更轻松地将URN字符串复制粘贴到您的网址中。这里是我做的一些作业:

有一个旧的实验RFC 2169它建议放在完整的urn字符串中,而不是%引号冒号(:)。这是干净的,优雅的......而且还有在野外如冒号的例子,

http://en.wikipedia.org/wiki/Talk:Buckminster_Fuller 

我的一个担心的(任何人都可以确认或拒绝此?)是,一些浏览器,服务器,框架或工具可能会尝试引用%或以其他方式扼杀冒号,因为他们可能会对冒号代表什么样的假设。

RFC 1630和其他RFC都没有说明是否可以在http方案的路径中使用冒号。然而,有一个警告!冒号的位置对于确定URL是否绝对是重要的(这在RFC 1630的“部分(相对)形式”一节中有详细说明)。如果冒号出现在斜线(/)之前,那么URL是绝对的。 (注意,冒号在RFC中被称为“保留”分隔符,但其预期的保留用途是明确的,并且不排除在路径中使用)。

我想在这里获得更多的想法......(并不是简单地将斜线编码为一切东西,因为它不够高雅)。

+0

我试过第一种方法,在URL中使用“:”,但iis拒绝它。它在查询字符串中是允许的,但不是路径的一部分。这是我的发现。这可能是因为我们正在使用无扩展名的网址。我们目前正在将其拆分为url。 – Eatdoku

+0

这是我的恐惧......对':'的不一致处理是非常不幸的,因为它会迫使URN和URL之间不兼容。我希望看到':'这个特殊问题的解释,以便我们可以在URL中看到更多的URN。与此同时,我想你可以解决:http:// {domain}/{somethinghere} /?urn = {full urn string} –

+2

...以及使用'/'分隔符的想法不是一个坏主意,如果urn = {full urn string}是不合适的。我曾考虑过“/”来界定自己......但是由于我的完美主义本质,我一直在一起黑我的工具来强制支持':'! –