171–179 of 179 posts
"QUERY is just GET" "Using GET with a Body works" Seems like this is going everyone's head. You're not supposed to use GET with a Body, this is a hack, therefore having an explicit method makes sense. Just because it works, doesn't mean its the right way
> Just because it works, doesn't mean its the right way Tell that to anybody in the business long enough to decipher someone else's Perl!
Earlier quoted context omitted.
But it's not existing behaviour. It does not already exist. Breaking the semantics of something that exists means that things will work inconsistently. Breaking the semantics of get will also create compatibility issues.
You might want to read the article.
Earlier quoted context omitted.
Even past the TLS point (CDNs terminate TLS, so they can read the body) there's a harder problem nobody's solved: to cache a QUERY the cache has to fold the body into the cache key, and there's no standard way to canonicalize a request body. {"a":1,"b":2} and {"b":2,"a":1} are the same query and two different cache entries; whitespace, float formatting, unordered keys all fork the key. GET gets this for free because…
> {"a":1,"b":2} and {"b":2,"a":1} are the same query and two different cache entries These two payloads are actually different. You're talking about semantics, which is determined by the payload format; in the case of JSON, these two are semantically similar. > GET gets this for free because the URL is already a normalized string It's the same principle; the order of properties matters too.
Earlier quoted context omitted.
There's no such thing as REST spec. The closes mechanism to actual REST is to create a resource using POST and then query it using GET. You have the added benefit of the resource being cacheable.
To clarify, by REST spec I meant the state of access defined by https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/... .
Earlier quoted context omitted.
The internet is complex, and you have tons of protocols that are not well supported. TCP/HTTP are well supported by proxies and have well-defined, stable specs, which also help with caching, throttling, etc. Just because it's old doesn't mean it is worse than alternatives, most likely it is quite the contrary.
Its worse than alternatives because it imposes greater complexity on everybody that uses it. COBOL is also old. That also does not mean COBOL is bad, but nobody wants to write COBOL any more when there are so many better options available.
HTTP accounts for roughly 70-80% of global web traffic, and if you narrow it to TCP-based application traffic, its dominance is closer to 95%. Comparing HTTP to COBOL is a bit like comparing trucks to bicycles...
Earlier quoted context omitted.
no, a POST that is idempotent. caching is an optional side benefit.
Isn't that just a PUT minus the inferred semantics?
PUT is idempotent but not safe.
Earlier quoted context omitted.
Isn't that just a PUT minus the inferred semantics?
yeah good catch, my response was incomplete. QUERY is a POST that is not only idempotent but also safe (it does not change anything at all on the server) (and it's cacheable of course) PUT is idempotent but not safe.
Earlier quoted context omitted.
The point is that if you do that, you end up with lots of undefined behaviour in existing software that has not been patched yet. If you make it a whole new request method, existing unpatched software should just respond with "Method not allowed".
Which means you have to structure everything around multiple scenarios anyway.