使用HTTP RESTful方法GET / POST /等。他们是多余的？ [英] Use of HTTP RESTful methods GET/POST/etc. Are they superfluous?
问题描述
RESTfulmethods的值是多少（例如GET，POST，PUT，DELETE，PATCH等）？ 为什么不让每个客户端都使用带有任何/所有相关参数，头文件，请求体，JSON等的GET方法。等等？ 在服务器端，每种方法的响应都是自定义&独立编码！ 例如，通过GET而不是POST发出数据库查询有什么不同？ 我知道GET用于不会更改数据库（或其他任何东西？）的查询。 我不认为中等（HTTP）RESTlike层是必要的。很显然。 假设我错了（我可能是）。难道还有很多REST服务器违反正确使用这些遭受零回响影响的协议吗？ 以下内容并不直接解决我的问题，而仅仅是在一场死亡音乐会上像一个酸涩的小石头一样在周围跳舞： 我花了大约80个小时尝试将PATCH传递给我的REST服务器（旧版Android Java不能识别更新的PATCH，所以我不得不在头中发出一个愚蠢的HTTP-OVERIDE-METHOD）。一个POST会工作正常，但系统不会因为他尊重REST而退出。 我只是不明白为什么要打扰每个单独的方法。他们似乎对Idempotence没有太大的影响。他们似乎只是准则。如果你违反这些准则，他们会给别人一个机会来指责你。
POST适用于进行更改的调用。但是，据我所知，RESTful标准并没有阻止人们编写服务器对GET的响应，并发出一个存储过程调用，确实会改变D B。反之亦然...... RESTful标准并没有阻止人们编写服务器对POST的响应，并发出一个确实不会改变ANYTHING的存储过程调用！
我只是困惑。请原谅我的帖子。
不是REST GET / POST / etc。方法多余？
什么是RESTful方法（即GET，POST，PUT，DELETE，PATCH等）？
首先澄清一下。那些不是RESTful方法;这些是HTTP方法。 Web是REST架构风格的参考实现（大部分）。
这意味着您的问题的权威答案记录在HTTP规范中。 / p>
但是，据我所知，RESTful标准并不妨碍用户将服务器响应编码为GET并发出存储过程调用确实会改变数据库。
HTTP规范将某些方法指定为 safe 。随便说一下，这表明一种方法是只读的;客户不负责任何可能发生在服务器上的副作用。
区分安全和不安全方法的目的是允许自动检索过程（spiders）和缓存性能优化（预取），无需担心会造成伤害。
但是你是对的，HTTP标准不会阻止您更改数据库以响应GET请求。事实上，它甚至会专门提出一个案例，您可以选择这样做：
通过在Web通常会收取广告帐户的费用。
HTTP规范还指定某些方法为 idempotent
在本规范定义的请求方法中，PUT，DELETE和安全请求方法是幂等的。
幂等方法？不可靠的网络
幂等方法的区别在于，如果在客户端能够读取服务器的响应之前发生通信故障，请求可以自动重复。
请注意，此处的客户端可能不是用户代理，而是参与对话的中间组件（如反向代理） 。
因此，如果我正在编写需要与服务器通信的用户代理或组件，并且服务器符合方法中的定义HTTP规范，那么我不需要知道任何有关应用程序协议的知识，以了解如何在GET，PUT或DELETE方法中正确处理丢失的消息。
另一方面，POST不会告诉我任何事情，并且由于未确认的消息可能仍在向您发送，因此发送消息的副本是非常危险的。
Isn'是否还有很多REST服务器违反正确使用这些遭受零反响的协议？
绝对 - 记住，超媒体的参考实现是HTML，HTML不包含支持PUT或DELETE。如果您想支持调用不安全操作的超媒体控件，并且仍符合HTTP和HTML标准，则POST是您唯一的选择。
这些准则不是比他们的价值更麻烦吗？
不是真的吗？他们在可靠性方面提供了真正的价值，他们为混合添加的额外复杂性非常小。
我只是不明白为什么要打扰每个单独的方法。他们似乎对幂等性没有太大影响。
它们不会影响它们，它们会传达它。
服务器已经知道它的哪些资源是幂等接收器 。这是客户和中介组件，它们需要信息。 HTTP规范使您能够将这些信息免费传递给任何其他兼容组件。
对每个请求使用最合适的方法意味着您可以将解决方案部署到商品组件的拓扑结构，并且正常运行。
或者，您可以放弃可靠的消息传递。或者，您可以在组件中编写一堆自定义代码，以明确告诉他们哪些端点是幂等接收器。
/ p>同一首歌，不同的诗。如果资源支持选项， GET 和 PATCH ，那么我可以发现我需要知道的执行部分更新的所有信息，并且可以使用我在其他地方使用的相同商品实现来完成此操作。
使用POST实现相同的结果是一项很多工作。例如，您需要一些机制来向客户端传达POST具有部分更新语义，以及在修补特定资源时接受哪些媒体类型。
$ b
通过在客户端上进行每次调用GET并且服务器通过关注请求而不是方法来实现这些功能，我会失去什么？
符合标准的用户代理可以假定GET是安全的。如果您在可通过GET访问的端点上产生副作用（写入），则允许代理预取端点作为优化 - 即使没有人期望它，副作用也会启动。
如果端点不是幂等接收器，那么您必须考虑GET调用可能会发生一次以上。
另外，用户代理和中介组件可以对缓存作出假设 - 请求您期望获得所有通向服务器的路径并不是这样，因为沿途一致的组件允许服务器将回复从他们自己的缓存中取出。
为了制作蛋糕，额外风险; 未定义的行为。
GET请求消息中的有效载荷没有定义的语义;发送一个GET请求的有效负载体可能会导致一些现有的实现拒绝请求。
我相信你来自哪里我不确定，更多的是RPC观点。客户端发送消息，服务器响应;只要对话中的参与者对消息的语义有一个共同的理解，如果消息中的文本显示为GET或POST或PATCH，那么这很重要吗？当然不是。
当RPC适合您要解决的问题时，RPC是一个很棒的选择。
但是......
RPC在网络规模上很难。你的团队能交付吗？您的团队可以提供具有成本效益的方式吗？另一方面，HTTP的规模相对比较简单;有一个巨大的好东西生态系统，使用可扩展的架构，它们是稳定的，经过测试的，了解得很好，而且价格低廉。轮胎已经完全被踢出去了。
你和你的团队几乎不需要做任何事情;有点阻碍和遵守HTTP标准，从这一点上，你可以专注于提供商业价值，而你陷入成功的坑中。
What is the value of RESTful "methods" (ie. GET, POST, PUT, DELETE, PATCH, etc.)?
Why not just make every client use the "GET" method w/ any/all relevant params, headers, requestbodies, JSON,etc. etc.?
On the server side, the response to each method is custom & independently coded!
For example, what difference does it make to issue a database query via GET instead of POST?
I understand that GET is for queries that don’t change the DB (or anything else?).
And POST is for calls that do make changes.
But, near as I can tell, the RESTful standard doesn’t prevent one to code up a server response to GET and issue a stored procedure call that indeed DOES change the DB.
Vice versa… the RESTful standard doesn’t prevent one to code up a server response to POST and issue a stored procedure call that indeed does NOT change the ANYTHING!
I’m not arguing that a midtier (HTTP) "RESTlike" layer is necessary. It clearly is.
Let's say I'm wrong (and I may be). Isn't it still likely that there are numerous REST servers violating the proper use of these protocols suffering ZERO repercussions?
The following do not directly address my questions but merely dance uncomfortably around it like an acidhead stoner at a Dead concert:
Different Models for RESTful GET and POST
RESTful - GET or POST - what to do?
GET vs POST in REST Web Service
I just spent ~80 hours trying to communicate a PATCH to my REST server (older Android Java doesn't recognize the newer PATCH so I had to issue a stupid kluge HTTP-OVERIDE-METHOD in the header). A POST would have worked fine but the sysop wouldn't budge because he respects REST.
I just don’t understand why to bother with each individual method. They don't seem to have much impact on Idempotence. They seem to be mere guidelines. And if you "violate" these "guidelines" they give someone else a chance to point a feckless finger at you. But so what?
Aren't these guidelines more trouble than they're worth?
I'm just confused. Please excuse the stridency of my post.
Aren’t REST GET/POST/etc. methods superfluous?
What is the value of RESTful "methods" (ie. GET, POST, PUT, DELETE, PATCH, etc.)?
First, a clarification. Those aren't RESTful methods; those are HTTP methods. The web is a reference implementation (for the most part) of the REST architectural style.
Which means that the authoritative answers to your questions are documented in the HTTP specification.
But, near as I can tell, the RESTful standard doesn’t prevent one to code up a server response to GET and issue a stored procedure call that indeed DOES change the DB.
The HTTP specification designates certain methods as being safe. Casually, this designates that a method is read only; the client is not responsible for any side effects that may occur on the server.
The purpose of distinguishing between safe and unsafe methods is to allow automated retrieval processes (spiders) and cache performance optimization (pre-fetching) to work without fear of causing harm.
But you are right, the HTTP standard doesn't prevent you from changing your database in response to a GET request. In fact, it even calls out specifically a case where you may choose to do that:
a safe request initiated by selecting an advertisement on the Web will often have the side effect of charging an advertising account.
The HTTP specification also designates certain methods as being idempotent
Of the request methods defined by this specification, PUT, DELETE, and safe request methods are idempotent.
The motivation for having idempotent methods? Unreliable networks
Idempotent methods are distinguished because the request can be repeated automatically if a communication failure occurs before the client is able to read the server's response.
Note that the client here might not be the user agent, but an intermediary component (like a reverse proxy) participating in the conversation.
Thus, if I'm writing a user agent, or a component, that needs to talk to your server, and your server conforms to the definition of methods in the HTTP specification, then I don't need to know anything about your application protocol to know how to correctly handle lost messages when the method is GET, PUT, or DELETE.
On the other hand, POST doesn't tell me anything, and since the unacknowledged message may still be on its way to you, it is dangerous to send a duplicate copy of the message.
Isn't it still likely that there are numerous REST servers violating the proper use of these protocols suffering ZERO repercussions?
Absolutely -- remember, the reference implementation of hypermedia is HTML, and HTML doesn't include support PUT or DELETE. If you want to afford a hypermedia control that invokes an unsafe operation, while still conforming to the HTTP and HTML standards, the POST is your only option.
Aren't these guidelines more trouble than they're worth?
Not really? They offer real value in reliability, and the extra complexity they add to the mix is pretty minimal.
I just don’t understand why to bother with each individual method. They don't seem to have much impact on idempotence.
They don't impact it, they communicate it.
The server already knows which of its resources are idempotent receivers. It's the client and the intermediary components that need that information. The HTTP specification gives you the ability to communicate that information for free to any other compliant component.
Using the maximally appropriate method for each request means that you can deploy your solution into a topology of commodity components, and it just works.
Alternatively, you can give up reliable messaging. Or you can write a bunch of custom code in your components to tell them explicitly which of your endpoints are idempotent receivers.
POST vs PATCH
Same song, different verse. If a resource supports OPTIONS, GET, and PATCH, then I can discover everything I need to know to execute a partial update, and I can do so using the same commodity implementation I use everywhere else.
Achieving the same result with POST is a whole lot more work. For instance, you need some mechanism for communicating to the client that POST has partial update semantics, and what media-types are accepted when patching a specific resource.
What do I lose by making each call on the client GET and the server honoring such just by paying attention to the request and not the method?
Conforming user-agents are allowed to assume that GET is safe. If you have side effects (writes) on endpoints accessible via GET, then the agent is allowed to pre-fetch the endpoint as an optimization -- the side effects start firing even though nobody expects it.
If the endpoint isn't an idempotent receiver, then you have to consider that the GET calls can happen more than once.
Furthermore, the user agent and intermediary components are allowed to make assumptions about caching -- requests that you expect to get all the way through to the server don't, because conforming components along the way are permitted to server replies out of their own cache.
To ice the cake, you are introducing another additional risk; undefined behavior.
A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.
Where I believe you are coming from, though I'm not certain, is more of an RPC point of view. Client sends a message, server responds; so long as both participants in the conversation have a common understanding of the semantics of the message, does it matter if the text in the message says "GET" or "POST" or "PATCH"? Of course not.
RPC is a fantastic choice when it fits the problem you are trying to solve.
But...
RPC at web scale is hard. Can your team deliver that? can your team deliver with cost effectiveness?
On the other hand, HTTP at scale is comparatively simple; there's an enormous ecosystem of goodies, using scalable architectures, that are stable, tested, well understood, and inexpensive. The tires are well and truly kicked.
You and your team hardly have to do anything; a bit of block and tackle to comply with the HTTP standards, and from that point on you can concentrate on delivering business value while you fall into the pit of success.
这篇关于使用HTTP RESTful方法GET / POST /等。他们是多余的？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
