.NET API 中的字符串或 URI? [英] Strings or URI in .NET APIs?

问题描述

我正在为 Netflix API 编写一个 .NET 包装器 API.

I am writing an .NET wrapper API for the Netflix API.

此时我可以选择将 URL 表示为字符串或 URI 对象.在我看来，两者都有很好的案例.

At this point I can choose to represent URLs as either strings or URI objects. Seems to me there is a good case for both.

因此，如果您使用 API，您更喜欢哪个?

So if you were using an API, which would you prefer?

推荐答案

以下引用来自:框架设计指南
我强烈向任何在 .Net 上开发框架的人推荐这本书

The below quote is from: Framework Design Guildelines
I highly recommend this book to anyone developing frameworks on .Net

务必使用 System.Uri 来表示 URI/URL 数据.
(对于参数，属性和返回值)

Do use System.Uri to represent URI / URL data.
(For Parameters, properties, and return values)

System.Uri 更安全、更丰富URI 的表示方式.广泛的使用 URI 相关数据的操作纯字符串已被证明会导致许多安全性和正确性问题.

System.Uri is a much safer and richer way of representing URIs. Extensive manipulation of URI-related data using plain strings has been shown to cause many security and correctness problems.

考虑为最常用的提供基于字符串的重载带有 System.Uri 参数的成员.

Consider providing string-based overloads for most commonly used members with System.Uri parameters.

在使用模式的情况下从用户那里获取字符串将是很常见，你应该考虑添加一个方便的重载接受一个字符串.基于字符串的重载应该在基于 Uri 的重载条款.

In cases where the usage pattern of taking a string from a user will be common enough, you should consider adding a convenience overload accepting a string. The string-based overload should be implemented in terms of the Uri-based overload.

请勿使用以下版本自动重载所有基于 Uri 的成员接受一个字符串.

Do Not automatically overload all Uri-based members with a version that accepts a string.

通常，基于 Uri 的 API 是首选.基于字符串的重载是意在成为最大的帮手常见场景.因此，你不应自动提供所有人的基于字符串的重载基于 Uri 的成员的变体.是有选择性地提供这样的帮手只为最常用的变种.

Generally, Uri-based APIs are preferred. String-based overloads are meant to be helpers for the most common scenarios. Therefore, you should not automatically provide string-based overloads for all variants of the Uri-based members. Be selective and provide such helpers just for the most commonly used variants.

编辑(根据评论):这本书特别指出:使用纯字符串对 URI 相关数据的广泛操作已被证明会导致许多安全性和正确性问题." 我不确定您想要使用 System.Uri/UriBuilder 的其他理由.此外，您为什么不想利用框架来读取/操作 URI?

EDIT (per comments): The book specifically states: "Extensive manipulation of URI-related data using plain strings has been shown to cause many security and correctness problems." I am not sure what additional justification you want for using System.Uri / UriBuilder. Additionally, why wouldn't you want to take advantage of the framework to read/manipulate a URI?

在设计供其他人使用的 API 时，重要的是让它们易于使用、以及可靠.出于这个原因，本书确实提到，您应该为常见功能提供不错"的重载.但是，为了确保正确性，您应该始终使用 URI 实现底层代码.

When designing an API that will be used by others it is important to make them approachable, as well as reliable. For this reason the book does mention, you should provide "nice" overloads for common functionality. However, to ensure correctness, you should always implement the underlying code with URIs.

您能否阐明您的需求或仅使用字符串的原因?

Can you please clarify your wants, or reasons to use only strings?

这篇关于.NET API 中的字符串或 URI?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！