我有一个包含Web服务的ASP.NET Web项目。当我运行该服务时,它会使用类似于http://api.example.com/game/service.asmx
的URL将我带到显示所有公开方法的页面。
在Web Service的代码中,有些方法具有以下属性:
[WebService(Namespace = "http://webservices.example.com/GameServices/Game1")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class Game1 : System.Web.Services.WebService
{
// code
}
我对为什么带有webService属性的类上的命名空间与Web服务的路径不同有点困惑。该命名空间来自哪里?它刚刚组成了吗?
答案 0 :(得分:36)
是的,已经弥补了。
听起来很傻,但这是真的。在您的代码中指定的命名空间将用于XML文档,这些XML文档作为特定Web服务的请求和响应进行交换。如果您在网络上放置网络跟踪程序,您将看到来回消息中使用的那些命名空间字符串。在webservices中,您的应用通常不需要关注命名空间。 webservices库通常会为您处理。
命名空间不需要是HTTP URL,但通常人们使用HTTP URL。这可能是您的大多数混淆的根源。 The IETF Recommendation for XML namespaces表明它应该是a URI,但该URI不必是HTTP URI,实际上它不需要附加任何“网络协议”。
命名空间是......一个字符串。它用作在XML模式中限定信息的简单方法。把它想象成一个人的姓氏。你可能认识几个名叫“克里斯”的人。你用它们的姓氏来区分它们。
类似地,元素名称“id”可以用在许多不同的XML文档和模式中。应用程序(以及人员)可以通过其xml命名空间区分使用qname“id”的许多不同元素。
通常,“信息架构师”会将文档或Web服务的XML命名空间指定为层次结构的URI,对于拥有组织是唯一的,并且与XML文档中的信息含义相关。 (在一个小型组织中,“信息架构师”只是一个开发人员。)例如http://mycompany.com/services/2013/customer可能是MyCompany的命名空间,在2013年创建并与服务有关,特别是与客户服务有关。
在我看来,没有真正的理由在XML命名空间的URI中使用http://
作为方案,除非您打算在该HTTP URI上提供文档。你也可以使用urn:mycompany.com/services/2013/customer作为XML命名空间。事实上它可能会更好,因为它表明它只是一个名称,它不是一个定位器。 (不是网址)。
我通常使用前缀为urn:
的URN作为方案,以指示命名空间只是一个名称,一个单一的名称。
修改强> URNs的结构有规则。基本格式为:
瓮:其中NID>:其中NSS>
...其中NID是名称空间标识,a set of special, approved strings和NSS之一是特定于名称空间的字符串。已批准的NID列表包括isbn,uuid,ietf和大约20个其他 - 每个都具有由不同的IETF RFC定义的特定含义。
尽管有关于NID的规则,但许多人根本不愿意遵守,并使用他们的域名代替NID来创建他们自己的URN。例如“mycompany.com”。 (这就是我经常做的事情。)
然后您可以选择如何进一步限定名称。您可以指定“服务”,以指示Web服务。有些人使用在命名空间中启动服务的年份和月份。这允许您更新服务,并使用不同的日期来区分不同的元素。遵循此命名约定的示例XML命名空间可能是:
urn:mycompany.com:services:2011:04:Game
这是RFC 2141称为“无效URN”的原因,因为我没有使用已注册的NID。但这符合我的目的。通过应用由RFC 4198定义的 fdc NID,将其转换为“有效URN”是一个简单的步骤。
urn:fdc:mycompany.com:services:2011:04:Game
看看它有多好?
最后,大多数人只是建立自己的命名约定,这对于XML数据的内部和合作伙伴使用者来说是有意义的。
答案 1 :(得分:2)
简而言之,是的,命名空间只是组成了。它们只是将一个文档与另一个文档区分开来的简单方法在命名空间中使用URL结构是最常见的,因为它们通常是唯一的。
答案 2 :(得分:1)
命名空间可以是您指定的任何值。我认为最佳做法是使命名空间与服务URL相同。