在工作中，我们遇到了区分大小写的REST api的问题，它忽略错误拼写的参数而不返回任何错误。在我看来这很糟糕。然后是一般问题：
REST API是区分大小写还是区分大小写？
每种方法有哪些优点和缺点？
答案 0 :(得分：34)
正如其他人所回答的那样，生成API的URL的HTTP部分区分大小写。这遵循UNIX约定，其中URI路径映射到文件系统路径，文件系统路径区分大小写。另一方面，Windows遵循其使路径不区分大小写的惯例。
但是，在Unix中使用两条路径只是大写不同的做法是不好的做法;此外，预计路径为小写。
因此：我们不要破坏惯例。
和
永远不应该共存。此外，products应优先于Products。 Products是否应返回404，301为products或仅为products的别名是风格问题 - 这是您的选择，但要保持一致。
Stack Overflow API规范地小写且不区分大小写。我认为这对客户来说是最简单的，同时具有明确的默认值并且对大多数用户来说并不令人惊讶。
毕竟，您能否想到一个客户从案例敏感度和重叠名称中真正受益？
答案 1 :(得分：33)
HTTP URL对方案和主机部分不区分大小写，对路径，查询和片段区分大小写。
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-25#page-19
答案 2 :(得分：10)
在工作中我们遇到了一个区分大小写的REST api的问题 错误拼写参数而不返回任何错误。在我看来 这很糟糕。
然后不要这样做。验证您的参数。强制执行“缺失”参数。首先不要发送错误的请求。符合API，特别是在正确拼写参数的这一级别，并不是一个沉重的负担。
REST API是区分大小写还是区分大小写？
如前所述，URL区分大小写，因此这里的谈判空间不大。向上/向下移动网址/参数会使每个人感到困惑，这会使您的网址不唯一。同样，期望实现者使用正确的URL并不是一个极端的要求。这些URL（很可能）不是由随机人员输入的，而是实现代码或网页。最后，这只会影响入口点URL。其余的URL应该是从有效负载中提取的直接副本，因为您正在关注HATEOAS。这些网址根本不应该被搞乱，而只是鹦鹉学舌。
简单地说，如果区分大小写是一个问题，那么你做错了。
每种方法有哪些优点和缺点？
优点是API的一致性，清晰度和正确执行。没有缺点。