是什么导致 Web 服务 URL 和命名空间之间存在差异？
我有一个包含 Web 服务的 ASP.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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
是的，这是编造的。
这听起来很愚蠢，但这是真的。代码中指定的命名空间将用于作为特定 Web 服务的请求和响应进行交换的 XML 文档。如果您在线上放置一个网络跟踪程序，您会看到消息中来回使用的那些命名空间字符串。在网络服务中，您的应用程序通常不需要关心名称空间。 Web 服务库通常会为您处理它。
尽管人们经常使用 HTTP URL，但名称空间不需要是 HTTP URL。这可能是您大部分困惑的根源。
XML 命名空间的 IETF 建议 建议它应该是 a URI，但该 URI 不必是 HTTP URI，事实上它不必具有附加到它的任何“网络协议”。
命名空间是...一个字符串。它用作限定 XML 模式中的信息的简单方法。把它想象成一个人的姓氏。您可能认识几个叫“克里斯”的人。您可以通过姓氏来区分他们。
类似地，元素名称“id”可以在许多不同的 XML 文档和模式中使用。应用程序（以及人们）可以通过其 xml 命名空间区分使用 qname“id”的许多不同元素。
通常，“信息架构师”会将文档或 Web 服务的 XML 命名空间指定为 URI，该 URI 是分层的、对于所属组织来说是唯一的，并且与 XML 文档中信息的含义相关。 （在小型组织中，“信息架构师”只是开发人员。）例如 http://mycompany. com/services/2013/customer 可能是 MyCompany 的命名空间，创建于 2013 年，与服务（特别是客户服务）相关。
在我看来，没有真正的理由使用
http://作为 XML 命名空间的 URI 中的方案，除非您计划在该 HTTP URI 上提供文档。您也可以使用 urn:mycompany.com/services/2013/customer 作为 XML 命名空间。事实上它可能更好，因为它表明它只是一个名称，而不是一个定位器。 （不是网址）。我通常使用 URN，以
urn:为前缀作为方案，以指示名称空间只是一个名称，一个唯一标识符。编辑
URN 的结构有一些规则。基本格式是：
...其中 NID 是命名空间 id，一组特殊的、经过批准的字符串，NSS 是特定于命名空间的字符串。批准的 NID 列表包括 isbn、uuid、ietf 和其他大约 20 个 - 每一个都具有由不同的 IETF RFC 定义的特定含义。
尽管有有关 NID 的规则，但许多人根本懒得去遵守，而是使用自己的域名来代替 NID 来创建自己的 URN。例如“mycompany.com”。 （这就是我经常做的事情）。
然后您可以选择如何进一步限定该名称。您可以指定“services”来指示 Web 服务。有些人使用命名空间中启动服务的年份和月份。这允许您更新服务，并使用不同的日期来区分不同的元素。遵循此命名约定的 XML 命名空间示例可能是：
RFC 2141 称之为“无效的 URN”，因为我没有使用注册的 NID。但这符合我的目的。通过应用由fdc NID，将其转换为“有效的URN”是一个简单的步骤rel="nofollow noreferrer">RFC 4198。
看看那好多少？
最后，大多数人只是建立自己的命名约定，这是对他们的用途、对 XML 数据的内部和合作伙伴消费者有意义的东西。
Yes, it is made up.
That sounds silly, but it's true. The namespace specified there, in your code, will be used on the XML documents that get exchanged as requests and responses for that particular web service. If you put a network trace program on the wire, you'd see those namespace strings used in the messages back and forth. In webservices, Your app need not concern itself with the namespace, usually. The webservices library usually takes care of it for you.
The namespace is not required to be an HTTP URL, though often people use HTTP URLs. This may be the source of most of the confusion on your part.
The IETF Recommendation for XML namespaces suggests that it should be a URI, but that URI need not be an HTTP URI, and in fact it need not have any "network protocol" attached to it.
The namespace is... a string. It is used as a simple way to qualify information in an XML schema. Think of it like a person's surname. You might know several people named "Chris". You distinguish them by their last names.
Similarly, the element name "id" may be used in many different XML documents and schema. Applications (and people too) can distinguish between the many different elements that use the qname "id" via their xml namespace.
Typically, an "information architect" will specify the XML namespace for a document or a webservice as a URI that is hierarchical, unique to the owning organization, and relevant to the meaning of the information in the XML document. (In a small organization the "info architect" is just a developer.) For example http://mycompany.com/services/2013/customer might be a namespace for MyCompany, created in 2013 and pertaining to services, and specifically the customer service.
In my opinion, there's no real reason to use
http://as the scheme in the URI for an XML namespace, unless you plan to make documentation available at that HTTP URI. You could just as well use urn:mycompany.com/services/2013/customer as the XML namespace. In fact it might be better, because it indicates it's just a name, it's not a locator. (not a web address).I normally use a URN, prefixed with
urn:as the scheme, to indicate that the namespace is simply a name, a uniquifier.EDIT
There are rules for the structure of URNs. The basic format is:
...where NID is a namespace id, one of a set of special, approved strings and NSS is a namespace-specific string. The list of approved NIDs includes isbn, uuid, ietf, and about 20 others - each one has a specific meaning defined by a distinct IETF RFC.
Despite the rules about NIDs, many people simply don't bother to conform, and coin their own URNs using their domain name in place of the NID. eg "mycompany.com". (This is what I do, often).
Then it's your choice how you want to qualify the name further. You can specify "services", to indicate a web service. Some people use the year and month the service was launched in a namespace. This allows you to update the service, and use a different date to distinguish between different elements. An example XML namespace following this naming convention might be:
This is what RFC 2141 calls an "invalid URN" because I didn't use a registered NID. But it serves my purpose. It is a simple step to transform it into a "valid URN" by applying the fdc NID, defined by RFC 4198.
See how much better that is?
In the end, most people just establish their own naming convention, something that makes sense for their uses, for internal and partner consumers of the XML data.
简而言之，是的，命名空间只是组成的。它们只是区分一个文档与另一个文档的简单方法。最常见的是在命名空间中使用 URL 结构，因为它们通常是唯一的。
In short, yes the namespaces are just made up. They're simply way to distinguish one document from another. It's most common to use a URL structure in your namespace because these are typically unique.
命名空间可以是您分配的任何值。我认为使命名空间与服务 URL 相同被认为是最佳实践。
The namespace can be any value you assign. I think it is considered best practice to make the namespace the same as the service URL.