Probably the main technical reason why I use the "wrong" method (POST) for read-only queries is because of all the layers of caching that I have to bust with GET requests. My internal APIs are typically for live data, so caching is not desirable. I've done the efforts before to use GET because it was the "right way". But in the end it was a lot of yak shaving that I could have avoided just by using POST.
Whatever people later appropriate HTTP methods to mean (e.g. REST), they already have pretty well-defined behaviors to most web servers. For example, GET requests also have a limited amount of data they can send (whatever length URL the web server will accept). And URLs are typically logged (also undesirable in many cases). So rather than ideologically trying to match up what someone says I should do, I try to match up the actual functionality with my needs.
That's also why I arrived at using request/reply messaging instead of REST. And using commands and queries instead of GraphQL. These allow me to focus on what the user is trying to learn and accomplish rather than being an exercise in munging data.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Probably the main technical reason why I use the "wrong" method (POST) for read-only queries is because of all the layers of caching that I have to bust with GET requests. My internal APIs are typically for live data, so caching is not desirable. I've done the efforts before to use GET because it was the "right way". But in the end it was a lot of yak shaving that I could have avoided just by using POST.
Whatever people later appropriate HTTP methods to mean (e.g. REST), they already have pretty well-defined behaviors to most web servers. For example, GET requests also have a limited amount of data they can send (whatever length URL the web server will accept). And URLs are typically logged (also undesirable in many cases). So rather than ideologically trying to match up what someone says I should do, I try to match up the actual functionality with my needs.
That's also why I arrived at using request/reply messaging instead of REST. And using commands and queries instead of GraphQL. These allow me to focus on what the user is trying to learn and accomplish rather than being an exercise in munging data.