[simon84]

This whole thing is non sense. It basically mixes technical constraints (body or not body) with a functional requirement that arises from people that are tied to semantics of the protocol.

HTTP is transfer protocol. It should not ever imply anything at the business level.

Yes REST made it's worst mistake out if it by giving a meaning to the verb.

Yes proxies rule how the body is re-interpreted in spite of the will of the sender (wtf).

But the original RFC states clearly that any verb can be used. This is how WebDav normalised its own.

But playing fancy by introducing a change that all HTTP implementation will have to honor is a very bad and irrational choice.

[pie_flavor]

Yes this, yes that, yes the other, because proxies are in agreement with patterns are in agreement with the HTTP spec that methods exist and have semantic and functional requirements. Your 'should' seems to be discussing a hypothetical technology that is not HTTP, because HTTP has worked this way since 1997.

[simon84]

You are correct, better concede than argue.

What I meant was a tangent: the HTTP was designed with a strong assumption that the application implementing it (the web server) would be the one providing the logic. Hence all the RFC terminology "should", "must", targeted at the implementor.

But very quickly, the logic was deferred to a layer on top (PHP,...) which would focus on the business aspect. The wiring was strong but the contract intent is loose (the requirements on the transport do not apply to the function).

Different layers, different people involved. What survived are the more or less conventions about it, which for the ease and limitations imposed by the protocol layer, led to infinite discussions about GET having a body or not.

The whole question arises because there is this clash between transport and logic that is wired on top, not built-in.

So while indeed, introducing QUERY solves a protocol gap, the people designing the business method never cared (or even knew) about that gap in the first place. This was another people's job to try to reconcile the two.

That's why I'm saying that digging into the initial assumption that the implementor of the HTTP is bound to business-level contraints is not reflecting the reality that has been going on since the early days of the dynamic web.