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

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

13 голосов
/ 19 апреля 2011

У меня есть веб-проект 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 отличается от пути к веб-службе.Откуда исходит это пространство имен?Это только что составлено?

Ответы [ 3 ]

36 голосов
/ 19 апреля 2011

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

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

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

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

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

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

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

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

EDIT Существуют правила для структуры URNs . Базовый формат:

урна:

... где 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», применив fdc NID, определенный RFC 4198 . 

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

Видите, насколько это лучше?

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

2 голосов
/ 19 апреля 2011

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

1 голос
/ 19 апреля 2011

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

...