11
我正在为Netflix API编写一个.NET包装器API。.NET API中的字符串或URI？
在这一点上，我可以选择将URL表示为字符串或URI对象。对我而言，这两者都是很好的例子。
所以，如果你使用的API，你更喜欢哪一个？
A
回答
17
下面的报价是：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实现基础代码。
您能澄清一下您的要求，还是只使用字符串的理由？
+0
提供链接到本书的奖励点，我直到现在才知道。 – OregonGhost 2008-10-18 11:20:58
+0
但是为什么？我读过这本书，实际上并没有证明这个决定是正确的。 – 2008-10-19 00:52:51
+0
您问，“为什么您不想利用框架来读取/操作URI？”。那么，大多数框架提供的用于处理URI的函数都是在字符串上工作，而不是System.Uri。这种认识是首先引发这个问题的原因。 – 2008-10-19 02:35:43
1
我会说你应该把它表示为URI。但是，如果我是您的API的用户，并且我不得不持续将基于字符串的URL转换为使用您的API的URI，那么我将是一个生气的用户。
我在说的是你需要评估什么样的受众会消费你的API。
0
一两件事，我发现的是，在写string -accepting方法，我总是无论如何都要初始化一个Uri对象只是为了验证字符串，使得UriFormatException会再传播出来的方法，如果用户通过一坏串。但是，如果您只接受Uri，正如我在FxCop（正确）大喊之后所做的那样，那么您始终知道您的输入是有效的 - 对我而言，这似乎是一个非常好的信号，表明您正在设计您的API。
小心分享你可以为两者做出的情况吗？ – Quantenmechaniker 2008-10-18 10:02:49