Coming from a non-traditional software engineering background (meaning I didn’t finish a college degree in computer science, or go to a bootcamp), I’ve had to piece together things from disparate sources of information.
I feel like this has largely worked for me, and has meant that I have a different, sometimes better, approach to certain aspects of development.
Unfortunately, I sometimes find out that I’ve got a huge blindspot in an area.
My initial experience with HTTP requests left me with the impression that GET requests are used to get information, and POST requests are used to pass information to the server.
For a variety of reasons, I’ve mostly needed to work with POST requests up to this point, but I do remember an instance where I was working with Google’s translation API, and I was shocked that making a call to translate some text was a POST call rather than a GET call. After all, I was requesting information (a translation) from their service.
As it turns out, there is a lot more going on there than I’d initially realized. GET requests are meant to be cacheable, and idempotent. Because of this, it is generally bad form to pass information in the request body. Everything is supposed to be contained in the URL…which in turn creates a limit in the number of parameters you can pass because there is a limit to the length of the URL that can be passed via a get request (~2,000 characters).
Google needed to be able to pass translation requests with more than 2000 characters to them. Additionally, they don’t want common translations to be cached and then served out to multiple customers. They want to be able to charge each individual customer for each translation, no matter how common the translation is.
There are likely other factors, but those two alone pretty much ensured that using a GET for that translation endpoint was a bad idea.
I found this medium post really helpful if you want a more detail explanation.