In case you're not sure what the difference between GET and POST in HTTP are (or what that sentence even means), here is a great post from today:
It got me thinking that there are definitely situations where folks hack on different methods to create the desired outcome. Sometimes GET is used alongside a "url param" password of sorts in contexts like one-click actions from an email (for unsubscribing or otherwise).
I also notice that, for example, Algolia uses a POST request for searches where I would expect a GET request. I think this is for mild performance improvements, or simply for consistency due to the fact that some of their requests probably should be triggered via POST.
Anyway, what are your thoughts about when to use the "wrong" method, or if this is ever advisable?
Latest comments (30)
Purist kind of annoy me. If it is my api and I'm the only one interacting with it, I'm gonna do what I need to do. If it is someone else's api, I'll use the verbs they insist upon.
If I recall from Algolia I think there's also side effects from your searches, so POST would make more sense there. I have mixed feelings about it I guess. Most of the time I think it's a good idea to stick to GET only returning stuff, and POST when you want to change the state of something on server side. Oh, yeah, and when you GET stuff then your params show up in your search history, so if you're including things like auth tokens or (gasp) password, that's very much not a good idea.
You can misuse them? Far out.
Like anything else, there are the die-hard theorists who say never break the pattern. But that isn't a good enough reason to listen.
A good reason to do things "correctly" is that your tooling will expect you to do it correctly. End users, if it's a public API or even public inside your company, will expect you to do it correctly. If you do it in a non-standard way, it may cause you to have to write additional documentation, which is an expense.
You have to weigh out each situation. When making an API, I'd stick to the convention unless I had a particularly good reason not to. One example is the GET with a token for password reset. Just obviously be aware of the implications - e.g. query params expose data. Make sure it's not sensitive or short-lived.
And writing a prototype isn't a good enough reason to skip convention. Many a production app is still running its prototype code.
It depends what it's intended to be used by and how it's misused.
GET requests shouldn't make changes. But I've been somewhere this was done internally by an API gateway and it was fine, and made it easy to test by pasting URLs into the browser address bar. I objected to this, but it didn't end up causing any problems.
However if there's a possibility these misused GET requests will be cached or spidered (in other words, if it's a public API, for some value of public), then it will probably lead to things breaking. I've heard a horror story of things getting deleted by web crawlers.
If a POST request is treated as "posting a command to an endpoint" I don't think it would cause problems as long as it's well-documented what the expected behavior is, even if that command is the equivalent of "give me information" or "delete something".
I don't give a fuck about methods purity, but there is a few properties to follow
Setting REST aside for a moment, the main issue with not using
GETfor read only requests is that you forego HTTP caching, which is a huge deal in many cases.I'm definitely pro trying to stick to the standard but also I think it's okay to bend it if necessary.
I don't agree with people saying "fudge it" on principle, just because it seems that they don't want to learn HTTP in the first place :D
I don't mind people using the "wrong" method.
What DRIVES ME FREAKING INSANE is when they do this but tell me it's a "REST API".
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.
When I was building software for the Army, we learned that certain request methods were blocked. For us, it was just one more drop in the it is what it is bucket.
Recently I've discovered that some of our applications return a failed authentication response as a 200 OK along with a validation messages object that says exactly the opposite.
It's my preference to be bothered by this type of thing. People meet, discuss, and make decisions about these things, so who am I to say, "Thanks for the suggestion, but I'll be going my own way."
Sometimes, though, it is what it is.