我了解了REST-ful API的基本概念，但我可以看到它们并不理想。我想知道以下假设我错在哪里。
REST-ful API不必要地公开模型
在REST-ful API上，它通常是一组操作，例如实体上的CRUD。有时执行业务操作需要操作许多模型，而不仅仅是一个。
例如，考虑退还订单的商业行为，然后降低买方的评级。这里涉及几种可能的模型，例如Order，OrderItem，Payment，Buyer，Refund。
我们经常最终将单个“父”模型暴露给更新自身及其子模型的操作，或者我们最终暴露出许多必须适当更新以成功完成业务操作的模型。
REST-ful API迫使人们在操纵模型方面进行思考而不是表达意图的自然行为
考虑客户服务评级应用程序。一旦支持电话结束，客户可以陈述他/她的幸福，例如“我很满意”/“我很生气”/“我是中立的”。
在REST-ful API中，客户必须弄清楚要操作的确切模型，以便说明他的感受。也许是CustomerResponse模型或反馈模型。为什么客户不能只是点击端点，识别自己并简单地说明他是否满意，而不必知道跟踪他的反应的基础模型？
REST-ful API更新操作过于简单
有时在模型上，您希望做的不仅仅是更新。更新可以是很多东西。
考虑Word模型。您可以反转字符，随机化字符，大写/小写字符，拆分单词以及实际意味着Word模型以某种方式“更新”的许多其他操作。
此时，仅在Word上公开Update操作可能会过度简化Word模型的丰富程度。
答案 0 :(得分：3)
我不相信你在上面提到的观点确实是RESTful API的缺点。更具分析性：
REST-ful API不必要地公开模型
没有模型暴露。一切都由一个控制器处理。唯一暴露给用户的是相应控制器的路径。
REST-ful API迫使人们在操纵模型方面进行思考而不是表达意图的自然行为
与上述相同。单个控制器可以处理不同的客户幸福状态。可以通过传递不同的后置参数（例如{state：“happy”}）来区分。
REST-ful API更新操作过于简单
在更新之前，没有什么可以阻止您操纵需要发送到模型的数据。在更新模型之前，您可以做任何您想做的事情，无论多么复杂。
最后，我认为RESTful API与其实现一样好。此外，我相信如果你想找到一个REST技术的缺陷，那就是你无法启动事务或推送通知服务器端
答案 1 :(得分：1)
首先，遵循REST架构约束的Web服务API称为RESTful API。基于HTTP的RESTful API由以下方面定义：
http://example.com/resources/ 现在提出问题：
REST-ful API不必要地公开模型
在您的示例中，如果您想要退款，您显然会使用多个型号。
RESTful并不意味着您只公开一个模型，例如，POST上的/api/refunds是一种RESTful方式，而不会暴露单个模型。
您从API获取的唯一内容是路由到不同控制器中的不同操作
REST-ful API迫使人们在操纵模型方面进行思考而不是表达意图的自然行为
您的RESTful API是从前端（智能手机应用程序，javascript应用程序等）或后端（服务器）调用的，最终用户（此处为满意/愤怒/中立客户端）不是我们有义务查看您的前端调用的网址，这里的满意度表格可以/support/survey，服务器API网址可以是POST到/api/support_calls/1/surveys。
REST-ful API更新操作过于简单
RESTful路由上的PUT NOT 表示您应该只更新一个模型。您可以操纵参数，创建模型，更新模型，然后更新主模型。
<强>最后
不要忘记RESTful架构是为开发人员创建的 ROUTE 和 URL 架构，您可以在控制器中执行任何操作，只是一种基于会议的方式，将您的网址公开给API的消费者
答案 2 :(得分：0)
我会尽力解决你的担忧，但请记住，这个话题是非常值得商榷的，所以请把这作为我的拙见......
1）关于模型是不必要的暴露，我认为这主要是以一种方式建模您的域实体，允许您以“在资源上做某事”的方式表达所有可用的操作和概念。在退款示例中，您可以为Refund实体建模并对其执行操作。
2）这里也是建模域实体和服务的问题。您的快乐服务可能是服务接受用户ID和表示用户满意度的整数。
3）在Word模型的情况下，您可以简单地使用PATCH（或PUT）http动词并提供简单地覆盖资源的服务，该服务又将由客户端操纵。
同样，REST是一种范例，因此它（除其他外）是一种组织域对象的方法以及可以对这些对象执行的操作。显然它有缺点和局限，但我个人认为它非常'透明'（即不对你的编程施加人为限制），而且它很容易使用，主要基于广泛接受的约定和技术（即http）动词等等。）