java - 重构不兼容 REST 的请求

Question

关闭。此题需要 details or clarity 。目前不接受答案。

---

想要改进这个问题吗？通过 editing this post 添加详细信息并澄清问题.

已关闭 4 年前。

Improve this question

我正在开发一个报告系统，该系统通过网络服务调用来提供图表数据。在某些情况下会进行搜索，在其他情况下会进行配置更新。

代码的 UI 端恰好是 Angular，后端是 Java，Oracle 作为持久存储。有趣的是，除了普通的 JDBC 之外，没有使用任何 Java 持久性框架。然而，我的问题至少不是直接涉及这些事情的。

几乎所有对资源之类的请求都是通过 POST 请求发出的。因此，获取特定报告的数据是一个 POST 请求，状态会在基于 JSON 的响应中返回(正常则有效，否则错误则无效)。

这不是我对 REST 标准的理解。我本以为开发人员应该对资源发出 GET 请求，通过查询字符串参数或请求 header 提供输入。改变状态或资源的调用将通过 POST 或 PUT 进行。

不遵循这些标准并只是滚动我们自己的范例并发布所有内容会产生什么后果？

Answer 1

What are the consequences to not following these standards and just rolling our own paradigm and just POSTing everything?

你放弃的是通用组件在理解请求是safe时可以提供的优势。 .

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

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

此外，如果一切都是 POST，那么您就会不断地从 HTTP 感知缓存中逐出表示。 Caching constraints在 REST 架构风格中很重要 - 我们可以从网络下载一次表示，然后重复使用它，这是扩展网络的关键部分。

HTTP 规范的一个有趣的地方是 304 Not Modified 不是 allowed response codes 之一。对于 POST 请求。没有与条件 GET 类似的东西。

当一切都是POST时，您正在采用应用程序协议(protocol)并将其转变为哑消息隧道，仅向通用组件提供对正在发生的事情的最弱的语义描述。

这并不一定意味着使用 POST 处理所有事情都是错误的。 SOAP 走的是这条路，GraphQL 似乎也正朝着这个方向发展。 HTTP 并未针对远程过程调用风格进行优化，但它是有能力的。