RESTful“方法”的价值是什么（即GET，POST，PUT，DELETE，PATCH等）？
为什么不让每个客户使用“GET”方法w / any / all params，headers，requestbodies，JSON等。等等？
在服务器端，对每种方法的响应是自定义＆amp;独立编码！
例如，通过GET而不是POST发出数据库查询会有什么不同？
我理解GET适用于不更改数据库（或其他任何内容？）的查询 POST用于进行更改的调用。
但是，据我所知，RESTful标准并不会阻止人们对GET的服务器响应进行编码并发出一个确实会更改数据库的存储过程调用。
反之亦然...... RESTful标准不会阻止用户编写服务器对POST的响应并发出一个确实不会改变ANYTHING的存储过程调用！
我并不是说中间层（HTTP）“RESTlike”层是必要的。显然是。
让我说我错了（我可能会）。难道很多REST服务器仍然可能违反正确使用这些协议的ZERO影响吗？
以下内容并没有直接解决我的问题，而只是像在死亡音乐会上的一个酸性傻瓜一样不舒服地跳舞：
Different Models for RESTful GET and POST
RESTful - GET or POST - what to do?
GET vs POST in REST Web Service
我只花了大约80个小时尝试将PATCH传送到我的REST服务器（较旧的Android Java无法识别较新的PATCH，所以我不得不在标题中发出一个愚蠢的kluge HTTP-OVERIDE-METHOD）。 POST本来可以正常工作但是sysop不会让步，因为他尊重REST。
我只是不明白为什么要打扰每个单独的方法。它们似乎对Idempotence没有太大影响。它们似乎只是指南。如果你“违反”这些“指导方针”，他们会给别人一个机会指着你的无耻手指。 但那是什么？
这些指南不是比它们的价值更麻烦吗？
我只是困惑。请原谅我的帖子的重要性。
不是REST GET / POST /等。方法多余？
答案 0 :(得分：2)
RESTful“方法”的价值是什么（即GET，POST，PUT，DELETE，PATCH等）？
首先，澄清一下。那些不是RESTful的方法;那些是HTTP方法。 Web是REST架构风格的参考实现（大部分）。
这意味着您的问题的权威答案记录在HTTP规范中。
但是，据我所知，RESTful标准并不能阻止人们对GET的服务器响应进行编码，并发出一个确实会更改数据库的存储过程调用。
HTTP规范将某些方法指定为safe。随便，这表示方法是只读的;客户端不对服务器上可能出现的任何副作用负责。
区分安全和不安全方法的目的是允许自动检索过程（蜘蛛）和缓存性能优化（预取）工作而不用担心造成伤害。
但是你是对的，HTTP标准并不能阻止你更改数据库以响应GET请求。事实上，它甚至特别提到了一个你可以选择这样做的案例：
通过在网络上选择广告而发起的安全请求通常会产生向广告帐户收费的副作用。
HTTP规范还将某些方法指定为idempotent
在本规范定义的请求方法中，PUT，DELETE和安全请求方法是幂等的。
拥有幂等方法的动机？不可靠的网络
区分幂等方法，因为如果在客户端能够读取服务器响应之前发生通信故障，则可以自动重复请求。
请注意，此处的客户端可能不是用户代理，而是参与对话的中间组件（如反向代理）。
因此，如果我正在编写需要与您的服务器通信的用户代理或组件，并且您的服务器符合HTTP规范中方法的定义，那么我并不需要了解有关应用程序协议的任何信息，以了解在方法为GET，PUT或DELETE时如何正确处理丢失的消息。
另一方面，POST并没有告诉我任何事情，并且由于未确认的消息可能仍在发送给您，因此发送消息的副本是危险的。
难道很多REST服务器仍然可能违反正确使用这些协议的ZERO影响吗？
绝对 - 记住，超媒体的参考实现是HTML，而HTML并不包括支持PUT或DELETE。如果您想要提供一个调用不安全操作的超媒体控件，同时仍然符合HTTP和HTML标准，POST是您唯一的选择。
Aren这些指导方针比它们的价值更麻烦吗？
不是吗？它们提供了可靠性的真正价值，并且它们为混合添加的额外复杂性非常小。
我只是不明白为什么要打扰每个单独的方法。他们似乎对幂等性没什么影响。
他们不会影响它，他们沟通。
服务器已经知道它的哪些资源是idempotent receivers。它是客户端和需要该信息的intermediary components。 HTTP规范使您能够将该信息免费传递给任何其他兼容组件。
对每个请求使用最合适的方法意味着您可以将解决方案部署到商品组件的拓扑中，并且正常工作。
或者，您可以放弃可靠的消息传递。或者，您可以在组件中编写一堆自定义代码，以明确告诉他们哪些端点是幂等接收器。
POST与PATCH
同一首歌，不同的诗句。如果资源支持OPTIONS，GET和PATCH，那么我可以发现执行部分更新时需要了解的所有信息，我可以使用我使用的相同商品实现在其他地方。
使用POST获得相同的结果是一项更多的工作。例如，您需要一些机制来与客户端通信，POST具有部分更新语义，以及修补特定资源时接受的媒体类型。
通过关注请求而不是方法，在客户端GET和服务器上进行每次调用，我会失去什么？
允许合规用户代理假设GET 安全。如果你在通过GET访问的端点上有副作用（写入），那么允许代理预取端点作为优化 - 即使没人预期，副作用也会开始触发。
如果端点不是幂等接收器，那么你必须考虑GET调用可以多次发生。
此外，允许用户代理和中间组件对caching做出假设 - 您希望一直到服务器的请求不会发生，因为整个过程中符合要求的组件是允许服务器回复自己的缓存。
为了榨干蛋糕，你又引入了另外一个风险; 未定义的行为。
GET请求消息中的有效负载没有定义的语义;在GET请求上发送有效负载主体可能会导致某些现有实现拒绝该请求。
我认为你来自哪里，虽然我不确定，但更多的是RPC的观点。客户端发送消息，服务器响应;只要对话中的两个参与者对消息的语义有共同的理解，如果消息中的文本说明了＆＃34; GET＆＃34;或＆＃34; POST＆＃34;或者＆＃34; PATCH＆＃34;？当然不是。
当RPC适合您要解决的问题时，它是梦幻般的选择。
<强>可是...
Web规模的RPC很难。你的团队可以提供吗？您的团队能否以具有成本效益的方式交付？
另一方面，HTTP规模比较简单;有一个巨大的好东西生态系统，使用可扩展的架构，稳定，经过测试，易于理解且价格低廉。轮胎很好，真正踢了。
你和你的团队几乎不需要做任何事情;为了遵守HTTP标准，我们可以采取一些阻止和解决方案，从那时起，您可以集中精力在实现业务价值的同时实现业务价值。