是不是要实现一个 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
是不是要实现一个 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
您不必像那样设计 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 设计而自动出现。
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
/all-posts/
/first-post
/some-stuff/second-post
/third-post
you still could provide an RESTful API to this. The Idea is that a GET
to /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.
A key aspect of REST is that the url is the resource. a uri like
http://example.com/script.php?etc-etc-etc
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:
http://example.com/posts?sort=date_asc&offset=20&limit=10
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
. PUT
and especially POST
methods should really use simple uri's with the resource that will be affected in only the path portion.
RESTful URI 设计都是关于资源访问的,它们应该以 RESTful 方式构造,所以你不应该有任何查询字符串。
例如 GET
作者/
作者/1
作者/1/书
作者/1/书/10
作者/1/书/10/摘要
等等
如今,任何事物都被称为 RESTfull,只要看看它的发明者 Roy Fielding 博士的一些回应,您就会得到一些想法。值得对此主题进行一些阅读。
PS 你的 URI 中不需要 post、get 等,HTTP 协议目前主要用于使用 REST API,你可以将动词作为调用的一部分传递。还有一个内容协商的概念,即您可以从 REST API (json,xml atc) 请求任何可用的格式。
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.
示例网址:
GET http://del.icio.us/api/
GET http://del.icio.us/api/peej/tags/
GET http://del.icio.us/api/peej/tags/test
DELETE http://del.icio.us/api/peej/bookmarks/[hash]
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.
这可能会有所帮助。参考: RESTful 服务 URL