Что вызывает разницу между URL-адресом веб-службы и пространством имен?

У меня есть веб-проект ASP.NET, содержащий веб-службу. Когда я запускаю службу, она выводит меня на страницу, показывающую все методы, которые отображаются, используя URL-адрес, похожий на http://api.example.com/game/service.asmx.

В коде для веб-службы есть методы, которые имеют следующие атрибуты:

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

Я немного смущен тем, почему пространство имен в классе с атрибутом webService отличается от пути к веб-службе. Откуда это пространство имен? Это только что составлено?

ОТВЕТЫ

Ответ 1

Да, он составлен.

Это звучит глупо, но это правда. Пространство имен, указанное там, в вашем коде, будет использоваться в XML-документах, которые обмениваются в качестве запросов и ответов для этой конкретной веб-службы. Если вы поместите программу трассировки сети в провод, вы увидите те строки пространства имен, которые используются в сообщениях назад и вперед. В веб-службах ваше приложение, как правило, не должно касаться пространства имен. Библиотека веб-сервисов обычно заботится об этом для вас.

Пространство имен не обязательно должно быть URL-адресом HTTP, хотя часто люди используют URL-адреса HTTP. Это может быть источником большей путаницы с вашей стороны. Рекомендация IETF для пространств имен XML предполагает, что это должно быть URI, но этот URI не обязательно должен быть URI HTTP, и на самом деле он не должен иметь никакого "сетевого протокола", прикрепленного к нему.

Пространство имен - это... строка. Он используется как простой способ определить информацию в XML-схеме. Думайте об этом как фамилия человека. Возможно, вы знаете несколько человек по имени "Крис". Вы отличаете их по фамилии.

Аналогично, имя элемента "id" может использоваться во многих разных документах и ​​схеме XML. Приложения (и люди тоже) могут различать множество различных элементов, которые используют qname "id" через их пространство имен xml.

Как правило, "информационный архитектор" будет определять пространство имен XML для документа или веб-службы как URI, который является иерархическим, уникальным для организации-владельца и имеет отношение к значению информации в документе XML. (В небольшой организации "архитектор информации" - это просто разработчик.) Например, http://mycompany.com/services/2013/customer может быть пространством имен для MyCompany, созданным в 2013 году и в отношении услуг и, в частности, обслуживания клиентов.

На мой взгляд, нет реальной причины использовать http:// в качестве схемы в URI для пространства имен XML, если вы не планируете сделать документацию доступной в этом URI HTTP. Вы могли бы также использовать urn: mycompany.com/services/2013/customer в качестве пространства имен XML. На самом деле это может быть лучше, потому что это указывает на это просто имя, это не локатор. (а не веб-адрес).

Обычно я использую URN с префиксом urn: в качестве схемы, чтобы указать, что пространство имен является просто именем, уникальным.

ИЗМЕНИТЬ Существуют правила для структуры URNs. Основной формат:

мкм: <NID> : < НСС >

... где NID - это идентификатор пространства имен, один из набор специальных утвержденных строк, а NSS - строка, специфичная для пространства имен. Список утвержденных NID включает в себя isbn, uuid, ietf и около 20 других - каждый из них имеет конкретное значение, определенное отдельным IETF RFC.

Несмотря на правила о NID, многие люди просто не утруждают себя соответствием и монета своими собственными URN, используя свое доменное имя вместо NID. например, "mycompany.com". (Это то, что я делаю, часто).

Тогда вы сами выбираете, как вы хотите квалифицировать имя дальше. Вы можете указать "службы", чтобы указать веб-службу. Некоторые люди используют год и месяц, когда служба была запущена в пространстве имен. Это позволяет вам обновлять службу и использовать другую дату для различения различных элементов. Пример пространства имен XML, следующего за этим соглашением об именах, может быть:

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

Это то, что RFC 2141 вызывает "недопустимый URN", потому что я не использовал зарегистрированный NID. Но это служит моей цели. Это простой шаг, чтобы преобразовать его в "действительный URN", применяя NID fdc, определенный RFC 4198,

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

Посмотрите, насколько это лучше?

В конце концов, большинство людей просто устанавливают свое собственное соглашение об именах, что имеет смысл для их использования, для внутренних и партнеров-потребителей данных XML.

Ответ 2

Короче говоря, да, пространство имен просто составлено. Это просто способ отличить один документ от другого. Наиболее часто используется структура URL-адресов в вашем пространстве имен, поскольку они обычно уникальны.

Ответ 3

Пространство имен может быть любым назначенным вами значением. Я считаю, что наилучшей практикой является создание пространства имен так же, как URL-адрес службы.