URL 始终区分大小写。但是，HOST 名称不是。
http://example.com/User?id=JohnDoe 和 http://ExAmPlE.cOM/User?id=JohnDoe 应该解析到相同的资源，即使 URL 不相同。但 URL 区分大小写。
由于规范指定 Users 而不是 users，因此大小写很重要。
这很重要，因为规范是这么说的。此外，如果不出意外，其他阅读规范的人将使用 Users 与 users。
关于 REST，这些 URL 无关紧要，因为 REST 不关心 URL。
但这不是 REST。这是一个基于 HTTP 的规范。它与 REST 无关。
附录：
他们可以随心所欲地称其为 REST API，但事实并非如此。他们还称其为“REST 协议”，这没有任何意义，因为 REST 是一种架构。 HTTP 是一种协议。您可以在 HTTP 之上构建一个 REST 架构的应用程序，但您不必这样做。 REST 与 HTTP 无关。
REST 不关心 URL，原因与您不关心的原因相同。 REST 中的一个关键原则是 HATEOAS，它本质上是识别资源中的链接并遵循它们。你知道亚马逊的“结帐”链接是什么吗？不？然而你仍然设法在那里购物？这可能是因为您点击了“结帐”链接，而不是因为您知道 URL 是什么。
在 REST 架构中正确设计的客户端只需遵循有效负载中提供给它的 URL。 URL 对它是不透明的。客户端只需要被告知服务的入口点（如果你愿意的话是主页），它可以通过它在有效负载中找到的众所周知的链接标识符 (rels) 自行从那里导航。
这个规范几乎没有。
在规范中考虑他们如何说版本控制是可选的。因此，这意味着 URL 可以是 /v1/Users 或只是 /Users。您在客户端中编码哪个 URL？你怎么知道有人在运行什么版本？如果您使用的服务之前没有版本化并变成了版本怎么办？您所有的 URL 都会中断。如果你想让一个协议在野外实现起来很愉快，可以在基础知识中添加可选元素，比如如何访问它。
考虑他们谈论从组中删除用户的 PATCH 部分。他们有：
"display": "Babs Jensen",
"value": "2819c223-7f76-453a-919d-413861904646"
"operation": "delete"
value 是什么？看起来像某种“用户ID”。然而，URL 应该是用户 ID。无论是http://example.com/Users/1234 或http://example.com/shippingdepartment/v1/Users/1234 或http://example.com/beta/notforpublication/Users/1234。这是一个唯一的标识符。 1234 告诉你什么？不够。
使用 HATEOAS，您的客户不必“知道”如何“构建”这些 URL 并弄错了。服务器告诉客户端这些是什么。
当您想要 GET：http://www.example.com/Users/1234 并且他们切换到 /v2 时会发生什么？在 HTTP 上的 REST 中，服务器可以使用 301 Moved Permanently 响应位置：http://www.beta.example.com/v2/users/4567/core。服务器刚刚告诉您的客户端此资源已移动。不仅是“ID”（1234 到 4567），还有路径（/Users/1234 到 /v2/users/4567/core），甚至是主机（www.example.come 到 www.beta.example.com） .您的客户怎么会知道如何构建新 URL？
所以，1234 是不够的。不透明的 URL 更加健壮。就像你在编程中不关心指针的值是什么一样，你只关心它指向什么，以及为什么指针数学会导致更多麻烦。
如果他们在这些组中使用 URL，那么您可以拥有跨域用户组！多么新颖的想法。您可以在同一组中拥有 v1 和 v2 用户。各种东西。
至于#2，子资源和其他什么，这是一个品味问题——你的品味，正如你所看到的，从高级 REST 的角度来看，客户并不关心你做什么。