REST API URL 必须是这样的吗？
是否真的要实现 RESTful API，必须实现一个如下所示的 URL 结构，
http://example.com/post/
http://example.com/post/123
其中 /123 将用于编辑、删除
另一种提问方式是：可以使用 URL看起来这叫RESTful？
http://example.com/script.php?method=get_title&blogid=123
Is it true that to implement a RESTful API, one has to implement a URL structure that looks like this
http://example.com/post/
http://example.com/post/123
where the /123 would be used for edit, delete
Another way to ask the question is: can a URL that looks like this be called RESTful?
http://example.com/script.php?method=get_title&blogid=123
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
您不必像那样设计 URI 结构。它也可以是
/some_obscure_string/base64_encoded_title/unique_id。这也可能是 RESTful，具体取决于其他几个因素。但是，关于如何在 RESTful Web 应用程序中设计 URI，有几种最佳实践，其中之一就是尽可能简单且尽可能易于人类阅读。
您的示例
http://example.com/script.php?method=get_title&blogid=123也可以是 RESTful，但查询参数表明某种 RPC-或 RMI-over-HTTP被用来代替。总结一下：不要在 URI 设计中考虑太多。这将通过应用程序的良好且正确的 RESTful 设计自动实现。
You don't have to design your URI structure like that. It could also be
/some_obscure_string/base64_encoded_title/unique_id. This could also be RESTful, depending on several other factors.But there are several best practices on how to design URIs in a RESTful web application and being as simple and as human readable as possible is one of them.
Your example
http://example.com/script.php?method=get_title&blogid=123could also be RESTful, but the query parameters indicate that some kind of RPC- or RMI-over-HTTP is used instead.To sum it up: Don't put too much thought into your URI design. This will come automatically with a good and proper RESTful design of your application.
REST 背后的理念是每个资源都有自己的 URL，并且您使用不同的 HTTP 方法与这些资源进行交互。定义 URL 结构是有意义的，以便不同资源之间的层次结构反映在 URL 中，但您不必这样做。
如果您有这样的 URL，
您仍然可以为此提供 RESTful API。这个想法是，
/all-posts/的GET返回每个帖子对象的 URL 列表，客户端使用这些 URL 与资源进行交互。基本上，客户端应将 URL 视为不透明数据。只要嵌入在客户端中的 URL 不更改，您也可以更改结构，而无需更改客户端。
您的示例 URL 可能不属于 RESTful API，因为它包含方法
get_title。在 REST 中，URL 代表一个事物。要对事物做什么（是否应该修改、是否应该检索其内容……）不是 URL 的一部分，因为 REST 使用不同的 HTTP 方法。The Idea behind REST is that every resource has it’s own URL and you use the different HTTP methods to interact with those resources. It makes sense to define the URL structure so that the hierarchy between different resources is reflected in the URL, but you don’t have to.
If you have URLs like this
you still could provide an RESTful API to this. The Idea is that a
GETto/all-posts/returns a list of the URLs of every post object and the client uses those URLs to interact with the resources. Basically the URLs should be treated as opaque data by the client.As long as the URL that is embedded in the client doesn’t change you also could change the structure without having to change the client.
Your example URL probably doesn’t belong to a RESTful API, since it contains a method
get_title. In REST a URL represents a thing. What is to be done with the thing (should it be modified, should it contents be retrieved, ...) is not part of the URL, for that REST uses the different HTTP methods.REST 的一个关键方面是 url 就是资源。像这样的 uri
不会将资源标识符放在 uri 的资源部分中。这并不是说 RESTful API 不应该使用 get 参数；事实上，这很好：
可能是获取最旧帖子第三页的 URI 的好方法。但是，以这种方式使用 get 参数只能用在方法也是
GET的请求中。PUT，特别是POST方法应该真正使用简单的 uri 以及仅在路径部分受影响的资源。A key aspect of REST is that the url is the resource. a uri like
doesn't put the resource identifier in the resource portion of the uri. that's not to say that a RESTful API shouldn't ever use get parameters; in fact, that's just fine:
might be a great way to get the URI's of the 3rd page of oldest posts. However, using get parameters in this way should only be used in requests where the method is also
GET.PUTand especiallyPOSTmethods should really use simple uri's with the resource that will be affected in only the path portion.RESTful URI 设计都是关于资源访问的，它们应该以 RESTful 方式构建，因此您不应该有任何查询字符串。
例如 GETauthors
/
authors/
1authors/1/booksauthors
/1/books/10authors
/1/books/10/summary
等。
现在任何东西都被称为 RESTfull，只需看看它的发明者的一些回应罗伊·菲尔丁博士和你会得到一些想法。值得对这个主题进行一些阅读。
PS，您的 URI 中不需要 post、get 等，HTTP 协议目前主要用于使用 REST API，您可以传递动词作为调用的一部分。还有一个内容协商的概念，即您可以从 REST API 请求任何可用的格式（json、xml atc）。
RESTful URI design is all about resources access and they should be structured in the RESTful manner, so you should not have any query strings.
e.g. of GET
authors/
authors/1
authors/1/books
authors/1/books/10
authors/1/books/10/summary
etc.
Anything and everything is called RESTfull these days, just look at some of the responses by it's inventor Dr Roy Fielding and you'll get some ideas. It is worth doing some reading on the subject.
P.S you do not need post,get etc in your URIs, HTTP protocol is at present mostly used for consuming REST APIs and you can pass verb as a part of the call. Also there is a concept of content negotiation i.e you can request any available format from REST API (json,xml atc).
REST 概念实际上基于以下事实：它是 URL 驱动的，而不是由大型数据块驱动的。使用 REST，您不必传递巨大的肥皂请求来调用方法 - 您的方法调用/对象创建/您想要执行的任何操作都只需通过 URL 以及您使用的动词与该 URL 来调用。
The REST concept is really based on the fact that it is URL driven, and not driven by large data-blobs. With REST, you don't have to pass a giant soap request to invoke a method - your method call/object creation/whatever you want to do is invoked simply by the URL, and the verb you used vs that URL.
URL 的结构并不重要。重要的是每个 URL 恰好标识 1 个资源。每个资源可以有多个指向它的 URL，但每个 URL 只能指向 1 个资源。
The structure of your URLs doesn't matter. What does matter is that each URL identifies exactly 1 resource. Each resource can have multiple URLs that point to it but each URL should only point to 1 resource.
示例 URL：
Example URLs:
这可能会有所帮助。参考：
RESTful 服务 URL
This can be helpful. Ref:
RESTful service URLs