是什么导致了web服务URL和名称空间之间的差异

本文关键字：空间 之间 web URL 服务 是什么 | 更新日期: 2023-09-27 17:50:26

我有一个ASP。包含web服务的。NET web项目。当我运行该服务时，它会将我带到一个显示所有公开方法的页面，使用类似于http://api.example.com/game/service.asmx的URL。

在Web服务的代码中，有以下属性的方法:

    [WebService(Namespace = "http://webservices.example.com/GameServices/Game1")]
    [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
    public class Game1 : System.Web.Services.WebService
    {
        // code 
    }

我有点困惑，为什么在一个类的命名空间与webService属性是不同的路径到web服务。这个名称空间是从哪里来的?只是编出来的吗?

是什么导致了web服务URL和名称空间之间的差异

是的,它是。

那听起来很傻，但却是真的。在代码中指定的名称空间将用于作为特定web服务的请求和响应交换的XML文档。如果在网络上运行网络跟踪程序，就会看到消息中来回使用的那些名称空间字符串。在web服务中，你的应用程序通常不需要关心名称空间。webservices库通常会帮你解决这个问题。

名称空间不需要是HTTP URL，尽管人们经常使用HTTP URL。这可能是你大部分困惑的来源。关于XML名称空间的IETF推荐建议它应该是一个URI，但这个URI不一定是HTTP URI，事实上它不需要有任何"网络协议"。附在上面

命名空间是…一个字符串。它被用作限定XML模式中的信息的一种简单方法。把它想象成一个人的姓氏。你可能认识几个叫"克里斯"的人。你可以通过他们的姓来区分他们。

同样，元素名称"id"可以在许多不同的XML文档和模式中使用。应用程序(以及人们)可以区分使用名称"id"的许多不同元素。通过它们的XML命名空间

通常，一个"信息架构"将文档或web服务的XML名称空间指定为一个URI，该URI是分层的，对拥有的组织是唯一的，并且与XML文档中信息的含义相关。(在小型组织中，"信息架构师";只是一个开发者。)例如，http://mycompany.com/services/2013/customer可能是MyCompany的名称空间，创建于2013年，属于服务，特别是客户服务。

在我看来，没有真正的理由在XML名称空间的URI中使用http://作为模式，除非您计划在该HTTP URI中提供文档。您也可以使用urn:mycompany.com/services/2013/customer作为XML名称空间。实际上可能更好，因为它表明它只是一个名称，而不是一个定位器。(不是网址)。

我通常使用以urn:为前缀的URN作为方案，以表明名称空间只是一个名称，一个惟一符。

编辑urn的结构是有规则的。基本格式为:

urn: & lt; NID> & lt; NSS>

…其中NID是名称空间id，是一组特殊的、经过批准的字符串之一，而NSS是特定于名称空间的字符串。已批准的nid列表包括isbn、uuid、ietf和大约20个其他nid，每个nid都有一个由不同的ietf RFC定义的特定含义。

尽管有关于NID的规则，但许多人只是懒得遵守，并使用他们的域名来代替NID来创建自己的urn。如"mycompany.com"(这是我经常做的)。

然后由您选择如何进一步限定名称。您可以指定"服务"来指示web服务。有些人使用该服务启动的年份和月份命名空间。这允许您更新服务，并使用不同的日期来区分不同的元素。遵循此命名约定的XML名称空间示例可能是:

 urn:mycompany.com:services:2011:04:Game

这是RFC 2141对"无效URN"因为我没有用注册的身份证。但它达到了我的目的。将其转换为"有效的unn"是一个简单的步骤。通过应用rfc4198定义的fdc NID 

 urn:fdc:mycompany.com:services:2011:04:Game

看到好多了吗?

最后，大多数人只是建立自己的命名约定，这对他们的使用、对XML数据的内部和合作伙伴消费者都有意义。

简而言之，是的，名称空间只是组成的。它们是区分一个文档和另一个文档的简单方法。最常见的是在名称空间中使用URL结构，因为这些结构通常是唯一的。

名称空间可以是您分配的任何值。我认为使名称空间与服务URL相同被认为是最佳实践。

相关文章：