清洁Rest中的URIs

Question

我正在为客户端设计一个新的web API。我以前没有设计过所谓的RESTful API，我对“做什么”和“不做什么”的大肆宣传的有效性有严重的怀疑。

也许是我，但有一件事我不明白，那就是为什么如此强调URI的结构。让 URI 表示资源，什么不表示。

然后，应用程序需要“预测”URI包含的内容，具有大量有效性代码和处理非自然URL结构的条件。

几个世纪以来，我们一直在使用这样的东西：

get_all_products.php

以及：

get_product.php?id=1234

只要一切都有据可查，我不明白为什么我们需要让应用程序变得更加复杂。

毕竟，我们不是在为搜索引擎创建API！

Answer 1

实际上，大多数人完全误解了Roy Thomas Fielding最初提出的内容，很少有所谓的RESTful应用程序是真正的RESTful。

在他的博客文章中，REST API必须是超文本驱动的，Roy表达了他对人们将基于HTTP的接口称为REST API的不满，而事实上他们不是。

RESTful 应用程序的关键要素之一是：

• 在输入 REST API 时，除了初始 URI（书签）和一组适合目标受众（即，任何可能使用 API 的客户端都希望理解）的标准化媒体类型之外，不应事先了解 REST API。从那时起，所有应用程序状态转换都必须由客户端选择服务器提供的选项来驱动，这些选项存在于接收的表示形式中，或者由用户对这些表示形式的操作所暗示。转换可以由客户端对媒体类型和资源通信html" target="_blank">机制的了解来确定（或限制），这两者都可以动态改进（例如，按需代码）。（这里的失败意味着带外信息正在推动交互而不是超文本。

这实际上是大多数普通网站的行为方式。

他在这里描述的不是人们认为他们在应用程序中使用URL重写和所谓的单一入口点实现的东西，它与主题无关！

如果除了初始 URI 之外不存在任何表示形式，并且服务器的响应没有提供进一步的链接，则实际上无法确定应用程序状态转换如何进行到该点之后。无论你如何构建URI以及它有多可预测，你都没有创建一个真正的RESTful应用程序。

使用URI，例如：

https://www.example.com/api/1.0/products/

可以使客户知道，如果在“产品/”部分之后输入“1234”，则获取特定产品。并且促进POST、PUT和DELETE方法可以进一步使客户端能够确定可以在该特定资源上执行哪些操作，但它仍然不是真正的RESTful应用程序，因为除此之外，无法仅使用服务器提供的选项继续。

你真正拥有的是带外信息驱动交互，而不是超文本，句号！

创建一个HTTP接口，确保你用清晰的复制/粘贴示例（没有假设）记录所有内容，只有KISS，不要遵循炒作！