I get why that's "yuck" but if I'd hedge a bet...it's probably done because it's easier to make a GET than it is a POST or PUT request and the length of a text message will never exceed the query string uri length limits.
Not saying I disagree, but i don't know it changes a whole lot in this case.
In this case maybe, but generally GET should be avoided for any creative/transactional action because many systems will replay/cache GET requests, assuming that they’re idempotent.
Yeah the caching issue is a great reason not to use a GET, i was more just suggesting if you're being lazy and pasting a request into a browser v's using a command line (which obviously you should) then it's easy to get going quickly to kick the tires.
If you really want to, you can in fact issue a POST with a query string and no body. It would admittedly be rather unusual.
Also, application/x-www-form-urlencoded bodies are literally identical to query strings anyway, so if you can construct a query string, you can easily construct a POST body using that Content-Type too.
How is a GET request easier? I assume you need to include authentication somehow, so it isn't like you are triggering it by typing the url in a browser.
just to point out: there are no uri length limits. browsers typically have one (I haven't checked lately tho), but other tools generally don't (except by mistake / size-capped buffers).
the spec does not define a limit, and the widely varying implementation-specific limits are soft evidence of that.
even wget and curl are probably more limited by your CLI arg length limits than the bins themselves. e.g. I can craft a multi-megabyte GET request in a file and pass it to `curl -K` and it works just fine (I just did so to verify, a bit over 3MB. google complained a bit, but it responded). even if I screwed that up somehow / it silently truncated, I can absolutely do something with netcat and know it won't truncate.
Not saying I disagree, but i don't know it changes a whole lot in this case.