REST URL 通常是如何定义的？
我知道 REST 的主要原则之一是为每个资源创建一个唯一的 URL。
我的问题是，这些 URL 通常是如何定义的？
I know that one of the main principles of REST is that you create a unique URL to every resource.
My question is, how are these URLs typically defined?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这由你决定。你应该让它有意义并尽可能坚持下去。
示例：
用于用户名和
用户集合。
您应该利用 URL 的分层性质来执行以下操作：
引用用户文档的列表。您应该非常小心地构建它。仔细考虑您的设计的潜在后果是什么，因为资源 URL 是您的服务最重要的设计决策之一。
That's up to you to decide. You should make it make sense and be as persistent as possible.
Examples:
for a username and
for the collection of users.
You should take advantage of the hierarchical nature of URLs to do stuff like:
To refer to the list of a user's documents. You should be very careful with how you structure this. Think carefully about what the potential consequences of your design are, because the resource URLs are among the most important design decisions for your service.
REST url 的定义方式与孩子的命名方式相同：有些人使用姓氏（现有的公司或项目标准），有些人查看婴儿名字书（标准文档？哈！），有些人向朋友寻求建议（朋友） 、邮件列表等），有些人推迟决定并使用默认名称，如“Baby Boy Smith”，并且稍后必须经历繁琐的重命名过程（301 重定向等），有些人拒绝告诉任何人他们的名字挑选的直到交货日。
简而言之，确实没有典型。标准表单生成的 url（带有 ?name=value&name=value 参数）是完全有效的 REST url。许多人喜欢将这些参数编码到斜线路径中，例如 http://example.com/restapi /name/value/name/value 或使用隐式位置名称，http://example.com /restapi/value1/value2。但您决不限于这些格式。
REST urls are defined the same way children are named: some people use family names (an existing corporate or project standard), some people look in a baby-names book (standards document? hah!), some people ask friends for advice (friends, mailing lists, etc), some people put off the decision and use default names like "Baby Boy Smith" and have to go through tedious renaming processes later (301 redirecte, etc), some people refuse to tell anyone what names they've picked until delivery day.
In short, there really isn't a typical. Standard form-generated urls (with ?name=value&name=value parameters) are perfectly valid REST urls. Many people prefer to encode those parameters into slashed paths, like http://example.com/restapi/name/value/name/value or with implicit positional names, http://example.com/restapi/value1/value2. But you are by no means restricted to those formats.
不管你喜欢什么。
URL 可以是完全不透明的，或者 URL 的路径可以传达期望的资源类型。
您可能希望遵循 HATEOAS 原则，并访问您所提供的超文本中的这些 URL，因此客户端只需要知道如何导航，而不需要知道如何构建某些 URL。
也就是说，您可以从根 URL 开始，并通过从那里导航来访问所有其他资源。
不要将自己束缚在特定的 URL 模板中。这只会妨碍您扩展和改进 REST API 的能力。
however you like.
The URL could be completely opaque or the path of the URL could convey what kind of resource to expect.
You might want to follow the HATEOAS principle and make access to those URLs part of the hypertext you are delivering, so clients only need to know how to navigate, not how to construct certain URLs.
I.e. you could start off a root URL and make all the other resources reachable by navigation from there.
Don't tie yourself into a specific URL template. This will only hamper your ability to extend and improve upon your REST API.
REST 是一种用于构建分布式系统的架构风格。这通常意味着您有一个客户端应用程序和一个服务器应用程序。当您的客户端应用程序需要访问服务器上的某些信息时，请创建一个可用于标识该信息的 URL。
URL 的结构对于客户端应用程序来说并不重要，因此无论您使用什么服务器框架，都可以使用最简单的结构。
REST is an architectural style for building distributed systems. Which generally means that you have a client application and a server application. When your client application needs to access some piece of information on your server, then create an URL that you can use to identify that piece of information.
The structure of the URL is not really important to the client application, so use whatever structure is easiest with whatever server framework you are using.