alt Hacker NewsThe situations where I've wished for GET to be able to have a (typically JSON) body were all in situations where the request isn't "user visible" in the first place. That is: API calls, SPA apps, ajax requests, that sort of thing. Not something people are really supposed to bookmark or call directly.
If today you're doing some JS-fu to make an ajax GET request then you already need to do something to have permalinks (if desired).
Completely worth bringing up and thinking about, but unless I'm missing something I don't think a QUERY verb will change all that much here?
> unless I'm missing something I don't think a QUERY verb will change all that much here?
The semantics are important. GET APIs are expected to be safe, idempotent, and cache-friendly. When you are unable to use GET for technical reasons and move to POST, suddenly none of the infrastructure (like routers, gateways, or generic http libs) can make these assumptions about your API. For example, many tools will not attempt to put retry logic around POST calls, because they cannot be sure that retrying is safe.
Having the QUERY verb allows us to overcome the technical limitations of GET without having to drop the safety expectations.