3 ms·
If i understand the common critique from the comments here it's that GET with a body, while not bad on its face, is nevertheless discouraged because you're gamb
by vsnf 5y ago
If i understand the common critique from the comments here it's that GET with a body, while not bad on its face, is nevertheless discouraged because you're gambling with any number of intermediate systems that may strip the body from the request.
But what about DELETE with body? It's similarly unspecified, but it seems to me to be of a different breed. The point made about GET is that, under the assumption of a theoretically idempotent and immutable operation, various caching systems can kick in and serve a request from any potential world-wide server. But a DELETE is by nature a mutating event, and will always need to be directed to some kind of principal server, meaning it should probably escape the caching the same way POST requests do.
Is it just as much a gamble to do DELETE with body as it is GET with body?
- dragonwriter 5y ago> If i understand the common critique from the comments here it's that GET with a body, while not bad on its face, is nevertheless discouraged because you're gambling with any number of intermediate systems that may strip the body from the request. That's a problem. > But what about DELETE with body? It's similarly unspecified, And faces the same risk that intermediate systems might reject it or strip the body, called out in RFC 7231. > But a DELETE is by nature a mutating event, DELETE is, more to the point, and despite being idempotent, expressly not cacheable, so there is no risk of getting served the wrong cached response based on the body being stripped. But, aside from the request not fitting the defined semantics of what DELETE means, you still have the risk of rejection or the request having the body stripped.