REST API URL 必须看起来像这样吗？

Posted 2023-03-31

【中文标题】REST API URL 必须看起来像这样吗？

【英文标题】：Do REST API URLs have to look like this?

【发布时间】：2010-10-30 08:29:54

【问题描述】：

是不是要实现一个 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

【参考方案1】：

你没有有这样设计你的 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 设计而自动出现。

【参考方案2】：

REST 背后的理念是每个资源都有自己的 URL，您可以使用不同的 HTTP 方法与这些资源进行交互。定义 URL 结构是有意义的，以便不同资源之间的层次结构反映在 URL 中，但您不必这样做。

如果你有这样的网址

 /all-posts/
 /first-post
 /some-stuff/second-post
 /third-post

您仍然可以为此提供 RESTful API。想法是 GET 到 /all-posts/ 返回每​​个帖子对象的 URL 列表，客户端使用这些 URL 与资源进行交互。基本上，URL 应该被客户端视为不透明的数据。

只要嵌入在客户端中的 URL 不变，您也可以更改结构而无需更改客户端。

您的示例 URL 可能不属于 RESTful API，因为它包含一个方法 get_title。在 REST 中，一个 URL 代表一个事物。对事物要做什么（是否应该修改，是否应该检索其内容，...）不是 URL 的一部分，因为 REST 使用不同的 HTTP 方法。

【参考方案3】：

REST 的一个关键方面是 url 是资源。一个类似的uri

http://example.com/script.php?etc-etc-etc

不会将资源标识符放在 uri 的资源部分。这并不是说 RESTful API 不应该使用 get 参数；事实上，这很好：

http://example.com/posts?sort=date_asc&offset=20&limit=10

可能是获取最旧帖子第 3 页的 URI 的好方法。但是，以这种方式使用 get 参数只能在方法也是 GET 的请求中使用。 PUT 尤其是 POST 方法应该真正使用简单的 uri 和只会在路径部分受到影响的资源。

【参考方案4】：

RESTful URI 设计都是关于资源访问的，它们应该以 RESTful 方式构造，所以你不应该有任何查询字符串。

例如获取的

作者/

作者/1

作者/1/书

authors/1/books/10

authors/1/books/10/summary

等等

如今，任何事物都被称为 RESTfull，只要看看它的发明者 Roy Fielding 博士的一些回应，您就会得到一些想法。值得阅读有关该主题的内容。

P.S 您的 URI 中不需要 post、get 等，HTTP 协议目前主要用于使用 REST API，您可以将动词作为调用的一部分传递。还有一个内容协商的概念，即您可以从 REST API (json,xml atc) 请求任何可用的格式。

【参考方案5】：

REST 概念实际上是基于它是 URL 驱动的，而不是由大型数据块驱动的事实。使用 REST，您不必传递巨大的肥皂请求来调用方法 - 您的方法调用/对象创建/您想做的任何事情都可以通过 URL 以及您使用的动词与该 URL 来调用。

【参考方案6】：

示例网址：

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]

【参考方案7】：

网址的结构无关紧要。重要的是每个 URL 都准确地标识了 1 个资源。每个资源可以有多个指向它的 URL，但每个 URL 只能指向 1 个资源。

【参考方案8】：

这可能会有所帮助。参考： RESTful service URLs