什麼導致Web服務URL和命名空間之間的差異？

我有一個包含Web服務的ASP.NET Web項目。當我運行該服務時，它會將我帶到一個顯示所有公開方法的頁面，使用類似於http://api.example.com/game/service.asmx的URL。什麼導致Web服務URL和命名空間之間的差異？

在有具有以下屬性方法爲Web服務代碼：

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

我了，爲什麼在與web服務屬性的類命名空間的路徑不同的有點困惑網絡服務。該名稱空間來自哪裏？它只是組成嗎？

來源

2011-04-18 chobo

的可能重複[什麼是XML命名空間？（http://stackoverflow.com/questions/128389/what-are-xml-namespaces-for） – 2011-04-18 23:15:07

是的，它是由它組成。

聽起來很愚蠢，但這是真的。在您的代碼中指定的名稱空間將用於XML文檔，該文檔將被交換爲特定Web服務的請求和響應。如果你在網絡上放置一個網絡跟蹤程序，你會看到來回消息中使用的這些名稱空間字符串。在web服務中，您的應用程序通常不需要關心名稱空間。 webservices庫通常會爲您提供幫助。

雖然通常人們使用HTTP URL，但命名空間並不需要是HTTP URL。這可能是你大部分困惑的根源。 The IETF Recommendation for XML namespaces建議它應該是a URI，但該URI不一定是HTTP URI，實際上它不需要附加任何「網絡協議」。

該命名空間是...字符串。它用作在XML模式中限定信息的簡單方法。把它想成一個人的姓。你可能會認識一些名叫「克里斯」的人。你用他們的姓氏來區分他們。

類似地，元素名稱「id」可以用在許多不同的XML文檔和模式中。應用程序（和人也可以）通過它們的xml名稱空間區分使用qname「id」的許多不同元素。

通常情況下，「信息建築師」將指定一個文檔或Web服務作爲一個URI，它是分層次的，獨特的所屬組織，以及相關的XML文檔中的信息的含義XML命名空間。（在一個小型組織中，「信息架構師」只是一名開發人員。）例如，http://mycompany.com/services/2013/customer可能是MyCompany的命名空間，創建於2013年，屬於服務，特別是客戶服務。

在我看來，在XML命名空間的URI中沒有真正的理由使用http://作爲方案，除非您打算在該HTTP URI下提供文檔。您可以使用urn：mycompany.com/services/2013/customer作爲XML名稱空間。事實上，它可能會更好，因爲它表明它只是一個名稱，它不是一個定位器。（不是網址）。

我通常使用一個URN，前綴爲urn:作爲方案，表示命名空間僅僅是一個名稱，一個uniquifier。

編輯有用於URNs的結構規則。基本格式是：

甕：<NID>：<NSS>

...其中NID是一個命名空間ID的a set of special, approved strings之一，NSS是一個特定的命名空間字符串。已批准的NID列表包括isbn，uuid，ietf和其他約20個 - 每個具有由不同的IETF RFC定義的特定含義。

儘管有關於NID的規則，但許多人根本不用遵守規則，並用自己的域名代替NID來硬幣化自己的URN。例如「mycompany.com」。（這是我經常做的事）。

然後，您可以選擇如何進一步限定名稱。您可以指定「服務」來指示Web服務。有些人使用服務在命名空間中啓動的年份和月份。這使您可以更新服務，並使用不同的日期來區分不同的元素。下面這個命名約定的一個例子XML命名空間可能是：

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

這就是RFC 2141稱之爲「無效URN」因爲我沒有使用已註冊的NID。但它符合我的目的。通過應用RFC 4198定義的NID（fdc NID），將其轉換爲「有效的URN」是一個簡單的步驟。

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

看看有多好？最後，大多數人只是爲XML數據的內部和合作者使用者建立自己的命名約定，這對他們的使用是有意義的。

來源

2011-04-18 23:23:49 Cheeso

我upvoted這個答案，但要指出，因爲標準確實聲稱命名空間必須是一個URI（在1.1中，它可能是一個IRI），它至少應該遵循URI或IRI的定義。 Cheeso使用的示例不是有效的URI，除非「mycompany.com」已註冊爲URN「名稱空間標識符」。見http://www.rfc-editor.org/rfc/rfc2141.txt。 – 2011-04-19 00:25:24

w3文檔中提到「不建議使用名稱空間聲明中的相對URI引用，包括相同文檔引用。」如果命名空間只是一個任意字符串，它如何被「棄用」？ – 2018-02-23 19:44:20

總之，是的命名空間只是組成。它們是區分一個文件和另一個文件的簡單方法。在命名空間中使用URL結構是最常見的，因爲它們通常是唯一的。

來源

2011-04-18 23:21:09

該命名空間可以是您分配的任何值。我認爲最好的做法是使命名空間與服務URL相同。

來源

2011-04-18 23:24:05

它可以是您分配的任何有效的URI，假定該URI是您要分配的。你不應該使用別人的URI。沒有最佳實踐說它應該與服務URL相同。 – 2011-04-18 23:26:25

什麼導致Web服務URL和命名空間之間的差異？

回答

相關問題