.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连续转换为URI以使用您的API，那么我将是一个生气的用户。

我所说的是，您需要评估哪些受众群体会使用您的API。

Answer 3

我发现的一件事是，在编写string - 接受方法时，我总是必须初始化一个Uri对象，只是为了验证字符串，这样UriFormatException就会然后，如果用户传递了错误的字符串，则传播出该方法。但是，如果你只接受Uri，就像我在被FxCop（正确地）大吼大叫之后所做的那样，那么你总是知道你的输入是有效的 - 这对我来说似乎是一个非常好的迹象表明你正在设计你的API正确。