我刚刚阅读了有关REST URL的内容，并看到了以下示例：
/ API /用户/的getUser
现在，如果通过HTTP使用动词GET访问它，这不是一个错误的URL，因为它描述了URL中的操作（GET）吗？
答案 0 :(得分：9)
这更像是一个惯例，而不是一个硬性规则，但我宁愿看到像/API/User/7123这样的东西。 GET / POST / etc描述了动作动词，因此将其放入url会使其变得多余。
在这种情况下，没有理由不遵循良好的成熟做法。
以下是一些好消息：Understanding REST: Verbs, error codes, and authentication
答案 1 :(得分：5)
更好的方法是使用/ API / User / 7123并使用GET / POST方法来表示操作
答案 2 :(得分：5)
没有 REST URL 这样的东西。事实上， REST URL 这个词几乎是一个矛盾的说法。 超媒体作为应用程序状态引擎约束保证URL无关紧要：无论如何，您只关注服务器提供给您的链接。您永远不会在任何地方看到，阅读或输入URI。 （就像浏览网页一样：你不看链接的URL，阅读它，记住它然后在地址栏中输入它;你只需点击它而不关心它实际上说的是什么。）< / p>
术语 REST URL 意味着您关心REST架构中的URL。但是，如果您关心REST体系结构中的URL，则表示您不是RESTful。因此， REST URL 是矛盾的。
[注意：正确的URI设计非常对于URI的URI，尤其是 I 部分非常重要。此外，漂亮的网址有很多良好的可用性原因。但是这两者与REST没有任何关系。]
答案 3 :(得分：3)
这不一定很糟糕......它更多地与您用来生成其余URL的框架有关。发布的@Infinity链接是一个很好的资源，但不要局限于集合理论，因为它可能会导致某些框架中的工作量过大。
例如，在使用DELETE方法之前，没有理由不想在/ API / Users / {id} / Delete上运行GET以显示“你确定”的消息类型。
答案 4 :(得分：1)
/API/User/GetUser不是RESTful。使用动词来识别资源并不是件好事。示例网址仍然有效，但也不是正确的。它与以下声明一样错误
String phoneNumber = "jhon@gmail.com";