重构非 REST 兼容请求

Question

我正在开发一个报告系统，该系统通过网络服务调用为图表数据提供服务。在某些情况下完成搜索，在其他情况下完成配置更新。代码的 UI 端恰好是 Angular，后端是 Java，Oracle 作为持久性存储。有趣的是，除了普通的 JDBC 之外，没有使用任何 Java 持久性框架。但是，我的问题至少与这些事情无关。几乎所有对资源之类的请求都是通过 POST 请求发出的。因此，获取特定报告的数据是一个 POST 请求，状态返回在基于 JSON 的响应中（OK 表示有效，ERROR 表示无效）。这不是我对 REST 标准的理解。我原以为开发人员应该对资源发出 GET 请求，通过查询字符串参数或请求标头提供输入。改变状态或资源的调用将通过 POST 或 PUT 进行。不遵循这些标准而只是采用我们自己的范例并发布所有内容的后果是什么？

Answer 1

不遵循这些标准而只是采用我们自己的范例并发布所有内容的后果是什么？

您放弃的是通用组件在了解请求是安全的情况下可以提供的优势。

例如，Web 浏览器可以通过主动获取您可能需要的资源表示来优化用户体验。

同样，在不稳定的网络上，如果响应丢失，通用组件可以知道重试请求——因为请求的语义保证这样做没有风险。

此外，如果一切都是 POST，那么您将不断从 HTTP 感知缓存中逐出表示。 缓存约束在 REST 架构风格中很重要——事实上我们可以从网络下载一次表示然后重新使用它，这是扩展网络的关键部分。

HTTP 规范的一个有趣的角落是，它304 Not Modified不是POST 请求的允许响应代码之一。没有条件 GET 的模拟。

当一切正常时POST，您正在采用一个应用程序协议并将其变成一个哑消息隧道，仅向通用组件提供对正在发生的事情的最弱可能的语义描述。

这并不一定意味着对所有内容都使用 POST 是错误的。SOAP 走的是这条路，而 GraphQL 似乎也在走这条路。HTTP 没有针对远程过程调用风格进行优化，但它是有能力的。