我有一个包含 Web 服务的 ASP.NET 网页项目。当我运行该服务时，它会将我带到一个页面，显示所有暴露出来的方法，使用的 URL 类似于 http://api.example.com/game/service.asmx。
在 Web 服务的代码中，有一些具有以下属性的方法：
[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服务。如果您在网络跟踪程序上，您可以看到这些命名空间字符串在请求和响应消息中来回使用。通常情况下，您的应用程序不需要关注命名空间。Web服务库通常会为您处理它。
尽管名称空间不一定是HTTP URL，但通常人们使用HTTP URL。这可能是您混淆的原因。XML命名空间的IETF建议建议它应该是URI，但该URI不必是HTTP URI，事实上，它不必附加任何“网络协议”。
命名空间是……一个字符串。它用作在XML模式中限定信息的简单方式。将其视为人的姓氏。您可能认识几个名叫“Chris”的人。通过他们的姓氏，您可以区分他们。
同样，元素名“id”可以在许多不同的XML文档和模式中使用。应用程序（和人）可以通过其XML命名空间区分使用qname“id”的许多不同元素。
通常，“信息架构师”将指定文档或Web服务的XML命名空间为具有层次结构、对所属组织唯一且与XML文档中信息的含义相关的URI。（在小型组织中，“信息架构师”只是开发者。）例如，http://mycompany.com/services/2013/customer 可能是MyCompany的命名空间，创建于2013年，涉及服务，特别是客户服务。
在我看来，没有什么真正的理由在XML命名空间的URI中使用http://作为方案，除非您计划在该HTTP URI上提供文档。您同样可以使用urn:mycompany.com/services/2013/customer作为XML命名空间，事实上这可能更好，因为它表明它只是一个名称，而不是一个定位器（不是网址）。
我通常使用以urn:为前缀的URN作为方案，以表示命名空间仅是名称和唯一标识符。
编辑 URN的结构有规则。URNs的基本格式为：
urn:<NID>:<NSS>
其中，NID是命名空间ID之一，是一组特殊且获得批准的字符串之一，NSS是命名空间特定的字符串。已批准的NID列表包括isbn、uuid、ietf等约20个其他名称空间ID，每个ID都有一个由不同IETF RFC定义的特定含义。
尽管有关NID的规则，但许多人只是不遵守，并使用自己的域名代替NID来创建自己的URN。例如“mycompany.com”。（这是我经常做的事情。
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相同。