Co powoduje różnicę między adresem URL usługi internetowej a przestrzenią nazw?

Question

Co powoduje różnicę między adresem URL usługi internetowej a przestrzenią nazw?

Mam ASP.NET projekt WWW zawierający usługę WWW. Kiedy uruchamiam usługę, to doprowadza mnie do strony pokazującej wszystkie metody, które są narażone, używając adresu URL podobnego do http://api.example.com/game/service.asmx.

W kodzie usługi Web znajdują się metody, które mają następujące atrybuty:

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

Jestem trochę zdezorientowany, dlaczego przestrzeń nazw w klasie z atrybutem webService różni się od ścieżki do usługi internetowej. Skąd pochodzi ta przestrzeń nazw? Czy to tylko zmyślone?

13

c#web-services asmx xml-namespaces

Author: TRiG, 2011-04-18

Source

3 answers

Krótko mówiąc, tak, przestrzenie nazw są po prostu złożone. Są po prostu sposobem na odróżnienie jednego dokumentu od drugiego. Najczęściej używa się struktury adresów URL w przestrzeni nazw, ponieważ są one zazwyczaj unikalne.

2

Author: Ben Cull,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-04-18 23:21:09

Przestrzeń nazw może być dowolną wartością, którą przypisujesz. Myślę, że najlepszą praktyką jest, aby przestrzeń nazw była taka sama jak adres URL usługi.

1

Author: Jason Yost,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-04-18 23:24:05

score 36 · Accepted Answer

tak, jest zmyślona.

Brzmi głupio, ale to prawda. Przestrzeń nazw określona tam, w kodzie, będzie używana w dokumentach XML, które są wymieniane jako żądania i odpowiedzi dla danej usługi internetowej. Jeśli umieścisz program do śledzenia sieci na przewodzie, zobaczysz te ciągi przestrzeni nazw używane w wiadomościach tam i z powrotem. W webservices, Twoja aplikacja nie musi zajmować się przestrzenią nazw, zazwyczaj. Biblioteka webservices zazwyczaj zajmuje się tym za Ciebie.

Przestrzeń nazw nie musi być adresem URL HTTP, choć często ludzie używają adresów URL HTTP. To może być źródłem większości zamieszania z twojej strony. zalecenie IETF dla przestrzeni nazw XML sugeruje, że powinien to być a URI, ale URI nie musi być URI HTTP, a w rzeczywistości nie musi mieć do niego żadnego "protokołu sieciowego".

Przestrzeń nazw jest... sznurek. Jest on używany jako prosty sposób kwalifikowania informacji w schemacie XML. Pomyśl o tym jak o nazwisko osoby. Może znasz kilka osób o imieniu "Chris". Odróżniasz ich po nazwiskach.

Podobnie, Nazwa elementu " id " może być używana w wielu różnych dokumentach XML i schematach. Aplikacje (i ludzie także) mogą rozróżniać wiele różnych elementów, które używają qname " id " za pomocą swojej przestrzeni nazw xml.

Zazwyczaj "architekt informacji" określa przestrzeń nazw XML dla dokumentu lub usługi internetowej jako URI, który jest hierarchiczny, unikalny dla posiadanie organizacji i istotne znaczenie informacji w dokumencie XML. (W małej organizacji "info architect" jest tylko deweloperem.) Na przykład http://mycompany.com/services/2013/customer może być przestrzenią nazw dla MyCompany, stworzoną w 2013 roku i odnoszącą się do usług, a w szczególności do obsługi klienta.

Moim zdaniem, nie ma prawdziwego powodu, aby używać http:// jako schematu w URI dla przestrzeni nazw XML, chyba że planujesz zrobić dokumentację dostępne pod TYM adresem HTTP URI. Równie dobrze możesz użyć urn:mycompany.com/services/2013/customer jako przestrzeń nazw XML. W rzeczywistości może być lepiej, ponieważ wskazuje, że to tylko nazwa, a nie lokalizator. (nie Adres www).

Zwykle używam urny, poprzedzonej urn: jako schematu, aby wskazać, że przestrzeń nazw jest po prostu nazwą, unikatem.

EDIT Istnieją zasady budowy urn . Podstawowy format to:

Urn: :

...jeśli NID jest identyfikatorem przestrzeni nazw, jednym z zbioru specjalnych, zatwierdzonych łańcuchów , A NSS jest ciągiem specyficznym dla przestrzeni nazw. Lista zatwierdzonych Nid zawiera isbn, uuid, ietf i około 20 innych-każdy z nich ma określone znaczenie zdefiniowane przez odrębne RFC IETF.

Pomimo zasad dotyczących Nid, Wiele osób po prostu nie zadaje sobie trudu, aby się dostosować i monetować własne urny za pomocą nazwy domeny zamiast NID. eg "mycompany.com". (This is what I zrobić, często).

To twój wybór, jak chcesz zakwalifikować nazwę dalej. Możesz określić "usługi", aby wskazać usługę internetową. Niektóre osoby używają roku i miesiąca, w którym usługa została uruchomiona w przestrzeni nazw. Pozwala to na aktualizację usługi i użycie innej daty do rozróżnienia różnych elementów. Przykładowa przestrzeń nazw XML zgodna z tą konwencją może być:

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

To jest to, co RFC 2141 nazywa "nieprawidłową urnę", ponieważ nie użyłem zarejestrowany NID. Ale to służy mojemu celowi. Jest to prosty krok, aby przekształcić go w "poprawną urnę" poprzez zastosowanie FDC NID, zdefiniowanego przez RFC 4198.

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

Widzisz, o ile lepiej?

W końcu większość ludzi po prostu ustanawia własną konwencję nazewnictwa, coś, co ma sens dla ich zastosowań, dla wewnętrznych i partnerskich konsumentów danych XML.