什么导致Web服务URL和命名空间之间的差异？
我有一个包含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服务的路径不同有点困惑。 该命名空间来自哪里？ 它刚刚组成了吗？
是的，它是弥补的。
这听起来很傻，但这是真的。 在您的代码中指定的命名空间将用于XML文档，这些XML文档作为特定Web服务的请求和响应进行交换。 如果您在网络上放置网络跟踪程序，您将看到来回消息中使用的那些命名空间字符串。 在webservices中，您的应用程序通常不需要关注命名空间。 webservices库通常会为您处理。
命名空间不需要是HTTP URL，但通常人们使用HTTP URL。 这可能是您的大部分混淆的根源。 IETF对XML命名空间的建议表明它应该是一个URI ，但该URI不必是HTTP URI，实际上它不需要附加任何“网络协议”。
命名空间是……一个字符串。 它用作在XML模式中限定信息的简单方法。 把它想象成一个人的姓氏。 你可能认识几个名叫“克里斯”的人。 你用它们的姓氏来区分它们。
类似地，元素名称“id”可以用在许多不同的XML文档和模式中。 应用程序（以及人员）可以通过其xml命名空间区分使用qname“id”的许多不同元素。
通常，“信息架构师”将文档或web服务的XML名称空间指定为分层的URI，对于所属组织是唯一的，并且与XML文档中的信息的含义相关。 （在一个小型组织中，“信息架构师”只是一个开发人员。）例如， http：//mycompany.com/services/2013/customer可能是MyCompany的命名空间，创建于2013年，与服务有关，特别是客户服务。
在我看来，除非您打算在该HTTP URI上提供文档，否则没有理由使用http://作为XML命名空间的URI中的方案。 您也可以使用urn：mycompany.com/services/2013/customer作为XML命名空间。 事实上它可能会更好，因为它表明它只是一个名称，它不是定位器。 （不是url）。
我通常使用一个URN，前缀为urn:作为方案，表示命名空间只是一个名称，一个uniquifier。
编辑 URN的结构有规则。 基本格式是：
瓮：
：
…其中NID是名称空间标识，是一组特殊的，已批准的字符串之一 ，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数据的内部和合作伙伴使用者来说是有意义的。
简而言之，是的，命名空间只是组成。 它们只是将一个文档与另一个文档区分开来的简单方法 在命名空间中使用URL结构是最常见的，因为这些通常是唯一的。
命名空间可以是您指定的任何值。 我认为最佳做法是使命名空间与服务URL相同。