.NET API中的字符串或URI？

Question

我正在爲Netflix API編寫一個.NET包裝器API。

在這一點上，我可以選擇將URL表示爲字符串或URI對象。對我而言，這兩者都是很好的例子。

所以，如果你使用的API，你更喜歡哪一個？

Answer 1

下面的報價是：Framework Design Guildelines
我高度推薦這本書給任何人開發的框架上的.Net

不要使用的System.Uri表示URI/URL數據。
（對於參數， 屬性和返回值）

System.Uri是一種更安全和更豐富的 表示URI的方式。廣泛的 使用 處理URI相關數據已被證明會導致 許多安全性和正確性 問題。

考慮爲具有System.Uri參數的最常用的 成員提供基於字符串的重載。

在情況下的 採取一個字符串從用戶的使用模式將是 很常見，你應該考慮 增加一個方便的重載 接受的字符串。基於字符串的 過載應該在 條款的基於Uri的過載中實現。

不要自動重載所有基於Uri的成員，版本爲 接受字符串。

通常，基於Uri的API優選爲 。基於字符串的重載是 ，意圖成爲最常見場景的助手。因此， 不應自動爲基於Uri的成員的所有 變體提供基於字符串的重載 。有 選擇性，並提供此類幫助 僅適用於最常用的 變體。

（每評論）編輯：書中明確規定：「使用普通字符串URI相關數據的廣泛操作已被證明會導致很多安全性和正確性的問題。」我不確定你想要使用System.Uri/UriBuilder的額外理由。另外，爲什麼你不想利用框架來讀取/操作一個URI？

當設計一個將被他人使用的API時，重要的是讓他們平易近人，以及可靠的。出於這個原因，本書確實提到，你應該爲常用功能提供「好」的重載。但是，爲了確保正確性，您應該始終使用URI實現基礎代碼。

您能澄清一下您的要求，還是隻使用字符串的理由？

Answer 2

我會說你應該把它表示爲URI。但是，如果我是您的API的用戶，並且我不得不持續將基於字符串的URL轉換爲使用您的API的URI，那麼我將是一個生氣的用戶。

我在說的是你需要評估什麼樣的受衆會消費你的API。

Answer 3

一兩件事，我發現的是，在寫string -accepting方法，我總是無論如何都要初始化一個Uri對象只是爲了驗證字符串，使得UriFormatException會再傳播出來的方法，如果用戶通過一壞串。但是，如果您只接受Uri，正如我在FxCop（正確）大喊之後所做的那樣，那麼您始終知道您的輸入是有效的 - 對我而言，這似乎是一個非常好的信號，表明您正在設計您的API。