rest - 这些是 REST-ful API 的有效缺点吗？

Question

我了解 REST-ful API 的基本概念，但我可以看出它们并不理想。我想知道我在以下假设中哪里错了。

REST-ful API 不必要地公开模型

在 REST-ful API 上，它通常是一组操作，例如实体上的 CRUD。有时执行一项业务操作需要操纵许多模型，而不仅仅是一个。

例如，考虑对订单进行退款的业务操作，这会降低买家的评级。这里涉及几种可能的模型，例如 Order、OrderItem、Payment、Buyer、Refund。

我们通常最终会通过更新自身及其子模型的操作来公开单个“父”模型，或者我们最终会公开许多必须适当更新才能成功完成整个业务操作的模型。

REST-ful API 迫使人们根据操纵模型而不是陈述意图的自然行为来思考

考虑一个客户服务评级应用程序。支持电话结束后，客户可以说出他/她的幸福感，例如“我很满意”/“我很生气”/“我很中立”。

在 REST-ful API 中，客户必须弄清楚要操作的确切模型才能表达他的感受。也许是 CustomerResponse 模型或 Feedback 模型。为什么客户不能直接到达终点、表明自己的身份并简单地说明他是否满意，而不必知道跟踪他的响应的基础模型？

REST-ful API 更新操作过度简化了

有时在模型上，您想要做的不仅仅是更新。更新可以是很多事情。

考虑一个 Word 模型。您可以反转字符、随机化字符、大写/小写字符、拆分单词和许多其他实际上意味着 Word 模型以某种方式“更新”的操作。

在这一点上，仅在 Word 上公开更新操作可能会过度简化 Word 模型的丰富程度。

Answer 1

我不相信您上面所说的几点是 RESTful API 的真正缺点。更具分析性:

REST-ful API 不必要地公开模型

没有模型暴露。一切都由一个 Controller 处理。唯一暴露给用户的是相应 Controller 的路由。

REST-ful API 迫使人们根据操纵模型而不是陈述意图的自然行为来思考

同上。单个 Controller 可以处理不同的客户幸福状态。可以通过传递不同的帖子参数来区分(例如 {state: "happy"})。

REST-ful API 更新操作过度简化了

没有什么能阻止您在更新模型之前处理需要发送到模型的数据。在更新模型之前，您可以做任何您想做的事情，无论它有多复杂。

最后，我相信 RESTful API 的好坏取决于它的实现。此外，我相信，如果您想找到 REST 技术的一个缺陷，那就是您无法在服务器端启动事务或推送通知