웹 서비스 URL과 네임 스페이스가 다른 이유는 무엇입니까?

웹 서비스가 포함 된 ASP.NET 웹 프로젝트가 있습니다. 서비스를 실행하면 http://api.example.com/game/service.asmx과 유사한 URL을 사용하여 노출 된 모든 메소드를 보여주는 페이지로 이동합니다. 다음과 같은 속성을 가지고 방법이있는 웹 서비스의 코드에서 웹 서비스 URL과 네임 스페이스가 다른 이유는 무엇입니까?

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

I는 웹 서비스의 속성을 가진 클래스의 네임 스페이스가 경로에 다른 이유를 통해 조금 혼란 스러워요 웹 서비스. 그 네임 스페이스는 어디에서 오는 것입니까? 그냥 만들어 졌나요?

출처

2011-04-18 chobo

[가능한 XML의 네임 스페이스는 무엇입니까?] (http://stackoverflow.com/questions/128389/what-are-xml-namespaces-for) –

예, 구성되어 있습니다.

바보 같지만 사실입니다. 거기에 지정된 네임 스페이스는 코드에서 특정 웹 서비스에 대한 요청 및 응답으로 교환되는 XML 문서에 사용됩니다. 유선 네트워크 추적 프로그램을 넣으면 앞뒤로 메시지에 사용 된 네임 스페이스 문자열을 볼 수 있습니다. 웹 서비스에서 앱은 일반적으로 네임 스페이스에 관심을 가질 필요가 없습니다. webservices 라이브러리는 보통 여러분을 대신해 처리합니다.

사람들이 종종 HTTP URL을 사용하지만 네임 스페이스가 HTTP URL 일 필요는 없습니다. 이것은 당신이 겪고있는 대부분의 혼란의 근원 일 수 있습니다. The IETF Recommendation for XML namespaces은 a URI이어야한다고 제안하지만 그 URI는 HTTP URI 일 필요는 없으며 실제로 "네트워크 프로토콜"이 필요하지 않습니다.

네임 스페이스는 ... 문자열입니다. 이것은 XML 스키마에서 정보를 검증하는 간단한 방법으로 사용됩니다. 그것이 사람의 성처럼 생각하십시오. 당신은 "Chris"라는 이름의 사람들을 알 것입니다. 당신은 성으로 구별합니다.

마찬가지로 요소 이름 "id"는 많은 다른 XML 문서와 스키마에서 사용될 수 있습니다. 응용 프로그램 (사람도)은 xml 네임 스페이스를 통해 qname "id"를 사용하는 여러 요소를 구별 할 수 있습니다.

일반적으로 "정보 설계자"는 문서 또는 웹 서비스의 XML 네임 스페이스를 소유 조직에 계층 적이며 XML 문서의 정보 의미와 관련이있는 계층 적 URI로 지정합니다. 소규모 조직에서 "정보 아키텍트"는 개발자 일뿐입니다. 예를 들어, http://mycompany.com/services/2013/customer은 2013 년에 만들어지며 서비스, 특히 고객 서비스와 관련된 MyCompany의 네임 스페이스 일 수 있습니다.

XML URI를 사용할 수 있도록 문서를 만들 계획이 아니라면, XML 네임 스페이스의 URI에서 http://을 스키마로 사용하는 진정한 이유는 없습니다. urn : mycompany.com/services/2013/customer를 XML 네임 스페이스로 사용할 수도 있습니다. 실제로 그것은 이름 일 뿐이므로 더 좋을 수도 있습니다. 위치 표시자가 아닙니다. (웹 주소가 아님).

나는 일반적으로 이름 공간이 단순히 이름 인 Uniquifier임을 나타 내기 위해 체계로 urn:이라는 접두어가 붙은 URN을 사용합니다.

편집 는 URNs의 구조에 대한 규칙이 있습니다.기본 형식은 다음과 같습니다

는

항아리 : <NID> : < NID 네임 스페이스 ID입니다 >

NSS ..., a set of special, approved strings 중 하나 NSS는 네임 스페이스 특정 문자열입니다. 승인 된 NID 목록에는 isbn, uuid, ietf 및 약 20 개의 다른 사람이 포함되어 있습니다. 각각은 고유 한 IETF RFC에 의해 정의 된 특정 의미를가집니다.

NID에 관한 규칙에도 불구하고, 많은 사람들은 NID 대신 자신의 도메인 이름을 사용하여 자신의 URN을 준수하기 만하면됩니다. 예 : "mycompany.com". (이것은 내가 자주하는 일입니다.)

그러면 이름을 어떻게 추가 할지를 결정할 수 있습니다. "서비스"를 지정하여 웹 서비스를 나타낼 수 있습니다. 어떤 사람들은 서비스가 네임 스페이스에서 시작된 년과 달을 사용합니다. 이를 통해 서비스를 업데이트하고 다른 날짜를 사용하여 여러 요소를 구별 할 수 있습니다. 이 이름 지정 규칙 다음 예제 XML 네임 스페이스는 다음과 같을 수 있습니다

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

이 내가 등록 NID를 사용하지 않았기 때문에 RFC 2141 "잘못된 URN"이라고 부르는 것입니다. 그러나 그것은 나의 목적을위한 것입니다. fdc NID (RFC 4198으로 정의)를 적용하여 "유효한 URN"으로 변환하는 간단한 단계입니다.

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

더 자세히보기.

결국 대부분의 사람들은 XML 데이터의 내부 및 파트너 소비자를 위해 자신의 용도에 맞는 고유 한 명명 규칙을 설정하기 만합니다.

출처

2011-04-18 23:23:49 Cheeso

나는이 답변을 upvoted했지만 주목할 것입니다. 표준에서는 네임 스페이스가 URI 여야한다고 (1.1에서는 IRI 일 수 있음) 말하기 때문에 최소한 URI 또는 IRI의 정의를 따라야합니다. "mycompany.com"이 URN "네임 스페이스 식별자"로 등록되어 있지 않으면 Cheeso에서 사용한 예제는 유효한 URI가 아닙니다. http://www.rfc-editor.org/rfc/rfc2141.txt를 참조하십시오. –

w3 문서는 "네임 스페이스 선언에서 같은 문서 참조를 포함하는 상대 URI 참조를 사용하지 않습니다."라고 말합니다. 네임 스페이스가 임의의 문자열 일 경우 어떻게 "비추천"할 수 있습니까? –

즉, 네 네임 스페이스가 바로 구성됩니다. 그것들은 한 문서를 다른 문서와 구별하는 단순한 방법입니다. 일반적으로 고유하기 때문에 네임 스페이스에서 URL 구조를 사용하는 것이 가장 일반적입니다.

출처

2011-04-18 23:21:09

네임 스페이스는 할당 한 값이 될 수 있습니다. 네임 스페이스를 서비스 URL과 동일하게 만드는 것이 가장 좋은 방법이라고 생각합니다.

출처

2011-04-18 23:24:05

할당 할 수있는 모든 유효한 URI 일 수 있습니다. 할당 할 URI는 귀하가 가정 한 것입니다. 다른 사람의 URI는 사용하지 않아야합니다. 서비스 URL과 동일해야한다는 모범 사례는 없습니다. –

웹 서비스 URL과 네임 스페이스가 다른 이유는 무엇입니까?

답변

관련 문제