【发布时间】：2022-01-28 17:47:03
【问题描述】：
在工作中，我们遇到了区分大小写的 REST api 的问题，它会忽略拼写错误的参数而不返回任何错误。在我看来，这很糟糕。然后是一般性问题：
REST API 应该区分大小写还是不区分大小写？
每种方法的优缺点是什么？
【问题讨论】：
标签： rest asp.net-web-api
【发布时间】：2022-01-28 17:47:03
【问题描述】：
正如其他人所回答的，构成 API 的 URL 的 HTTP 部分区分大小写。这遵循 UNIX 约定，其中 URI 路径映射到文件系统路径，并且文件系统路径区分大小写。另一方面，Windows 遵循使路径不区分大小写的惯例。
但是，在 Unix 中，只有两个大小写不同的路径是不好的做法；此外，预计路径是小写的。
因此：我们不要打破常规。
和
永远不应该共存。此外，products 应优先于 Products。 Products 是否应该返回 404、301 到 products 或者只是作为 products 的别名，这是一个风格问题——这是你的选择，但要保持一致。
Stack Overflow API 是规范的小写和不区分大小写的。我认为这让客户的生活变得更轻松，同时具有明确的默认设置并且对大多数用户来说并不令人惊讶。
毕竟，您能想到一个诚实地受益从区分大小写和重叠名称的客户吗？
【讨论】：
-
很棒的答案，作为旁注，虽然 SO 有小写 URL，但它们不区分大小写。更改 URL 中的大小写，它将登陆同一页面，而不是重定向。
-
我也对 SO 如何处理规范化感兴趣 - 例如，此链接上的规范链接标签：stackoverflow.com/questions/21001455/… 似乎指向自身 - 这不会导致内容重复问题搜索引擎？
-
@MatthewAbbott 搜索引擎通过查看
<link rel="canonical".../>或<meta property="og:url".../>来消除歧义。我们还将 301 多个页面添加到他们的规范 URL。 -
@Sklivvz 我明白这一点，但鉴于 view-source:stackoverflow.com/questions/21001455/… 和 stackoverflow.com/questions/21001455/… 都返回相同的内容，并且都具有指向不同的规范和开放图形 URL 标记URL - 内容重复并且没有 301？当然不管大小写，这些 URL 都应该有相同的
canonical/og:url标签？ -
对“这是预期的”、“这是一种不好的做法”有任何参考吗？我们应该在记录的协议、工程规范或类似事实中支持我们的答案，以避免基于意见的工程。
HTTP URL 对于方案和主机部分不区分大小写，而对于路径、查询和片段则区分大小写。
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-p1-messaging-25#page-19
方案和主机 不区分大小写，通常以小写形式提供；所有其他 组件以区分大小写的方式进行比较。
【讨论】：
-
好的，我们这些开发人员应该如何设计 REST API？我发现设计区分大小写的 API 存在更多问题。
-
@mynkow 实际上 REST 使得处理区分大小写的 URI 变得非常容易。通过使用带有链接和 URI 模板的超媒体，服务器可以确保所有 URI 都具有正确的大小写。客户永远不必担心它。客户端只是从表示中读取 URIs/URITemplates 并遵循它们。
-
我对这个答案投了赞成票，原因如下：Web API 是在 HTTP 之上定义的，因此它们应该尽可能地尊重 HTTP 约定。我同意 Darrel 的观点，即超媒体是一种避免拼写错误导致问题的有用方法。
在工作中，我们遇到了一个忽略大小写的 REST api 问题 拼写错误的参数没有返回任何错误。在我看来 这很糟糕。
那就别这样了。验证您的参数。强制执行“缺失”参数。首先不要发送错误的请求。遵守 API，尤其是在正确拼写参数的水平上，并不是一个沉重的负担。
REST API 应该区分大小写还是不区分大小写？
如前所述，URL 区分大小写，因此这里确实没有太多协商的余地。升/降 urls/parameters 混淆了每个人，它使你的 URLs 不是唯一的。同样，期望实现者使用正确的 URL 并不是一个极端的要求。这些 URL（很可能）不是由随机人输入的，它们是实现的代码或网页。最后，这只影响入口点 URL。其余的 URL 应该是从有效负载中提取的直接副本，因为您正在关注 HATEOAS。这些 URL 根本不应该被弄乱，而只是鹦鹉学舌。
简单地说，如果区分大小写是个问题，那你就错了。
每种方法的优缺点是什么？
优点是 API 的一致性、清晰性和正确执行。没有缺点。
【讨论】：
-
URL 不区分大小写。文件系统可能区分大小写，这会对 URL 产生连锁反应。
-
@phill 您能否提供参考，因为我 99.9% 确信 Rfc7320 表示 http URL 的路径和查询区分大小写
-
@DarrelMiller tools.ietf.org/html/rfc7320 既不区分大小写也不区分大小写。
-
tools.ietf.org/html/rfc3986#section-6.2.2.1 "方案和主机不区分大小写，因此应规范化为小写...除非方案另有明确定义，否则假定其他通用语法组件区分大小写"假设是因为它取决于实现，即由您决定。
-
@pbreitenbach，正如 Darrel 前面提到的，在 RFC 7320 中，HTTP URL 区分大小写，但主机和方案除外。第 2.7.3 节说“方案和主机不区分大小写，通常以小写形式提供；所有其他组件以区分大小写的方式进行比较。”。查询字符串是 URL 的一部分。 POST 参数仅取决于资源如何解释它们，因此未指定。通用 URI 不指定，因为各个方案控制 URI 的 scheme://hostname 部分之后的所有内容。