How do you feel about the "misuse" of HTTP methods?

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:

Difference Between Those HTTP Requests

Milecia ・ Jun 18 '19

#beginners #webdev #http #server

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?

Comments

[Ayush Jain]

That's a Great thread, would be eagerly waiting for responses...

[Ben Halpern]

We haven't fully announced this yet because we want to add some follow-on functionality for managing notifications but you can now "follow" threads and get notified of each reply via the post's "three dots" menu.

😋

[Dor Shinar]

I think that REST is not perfectly suitable for contemporary applications, which are simply too complicated for it to handle gracefully. The simplest example I can give is a /login, where no conventional method works (you're not GETting information, not POSTing nor PUTting some payload [and dear God don't use DELETE]). The ultimate solution would be a combination of REST and RPC of some sort, in my mind.

Lately I've been getting into GraphQL and I gotta say I fell in love with it, as I feel it is the replacement of REST I've looked for. They opted to put the whole query in a POST request (be it GET, POST, PUT or DELETE equivalent), but in a nice structure that is easy to follow and manage.

[Anwar]

Actually the more I build complex apis, the more It messes my head around to stick with REST because of consistency issues.

For example, I would have a route to display all the shoes in a shoe store in GET /api/shoe, but getting the users liked shoes would be used through Post /api/shoe/liked because I authenticate the user with a JWT and I prefer to use a POST parameter because of the limit in GET queries and the fact post parameters are less easy to sniff than get... But this would work fine in GET because my tokens are not so long and my urls quite short but I do this to prevent any issues.

Also, it has for a moment make me wonder how complex it is to stick with only GET,POST,PUT,DELETE. An example is when you want to provide an "undo" feature.

Say you can trash a comment, or remove it permanently. Trashing would be seen as the equivalent of soft deleting, so why not use DELETE. But then you have the actual deletion, or maybe named destruction. Will you use DELETE to do this? Then the classic REST schema does not work anymore.

I feel like you, today REST gets less and less optimal for complex apps, GraphQL seems to be more suited.

[Andrew Brown 🇨🇦]

I briefly worked at one company where a senior developer forced everyone to use "GET" only for static page requests and "POST" only for api calls.

It was insanity.

[Karl N. Redman]

I don't care. Not at all.

What I mean by saying this is that the problem, in this situation, dictates the solution. @nielsoftware seems to have a great workflow while @dorshinar has a great point relative to API. The commonality seems to be scope and scale.

This concept irks me. Scope and Scale are restrictions (constructs) from an engineering point of view. Forcing a different paradigm among constructs is a basic programming no-no. I'd say the issue is a) under engineered and is a one-off b) under engineered and perceived to be a one-off c) over engineered and has too many options d) lacks clarity in it's definition.

my 2 cents

[Austin S. Hemmelgarn]

I guess it depends on what you're doing. Logic I use for determining things like this:

• If there's a method that exactly matches the required semantics, use it. Usually, this translates to GET, PUT, DELETE, or PATCH in my experience.
• If it doesn't modify server-side state and is cachable, it's a GET request.
• If it does modify server-side state, but is idempotent, it's a PUT request unless some other request has specific semantics that fit better.
• Otherwise, it's a POST request, probably with headers to prevent caching.

The thing is, in reality, if your request doesn't actually fit the first three cases, there arguably isn't a HTTP method that does exactly what you want, and it just makes the most sense to use the de-facto standard catch-all method.

[Marek Zaluski]

A one-time action URL as a GET request does break the idempotency property, but what else are you going to do?

At the end of the day the pragmatic solution is best. Solve the problem while introducing as few side problems as possible. And keep it simple -- that's my general philosophy.

The real rabbit hole of the HTTP methods debate is once you get into the semantics of PUT/DELETE and frankly I don't see the advantage.

GET and POST have the simplest semantics and you can build APIs that are super clear, pragmatic and easy to use with just those two methods, occasionally bending the rules when it's helpful but keeping things as predictable as possible.

[Meghan (she/her)]

Why you should use standard HTTP methods when designing REST APIs

Suhas Chatekar ・ Feb 23 '17 ・ 7 min read

#rest #http #api

[Chad Tiffin]

That article doesn't give a strong argument against ONLY using get/post IMO. His main point is to maintain idempotency, but you don't need all the extra verbs beyond get and post to do that.

[Dashiell Bark-Huss]

"what else are you going to do"- The way to do it inline with HTTP standards is that the email link sends the user to a form where they click "confirm email" and that form sends a patch request. If you instead alter the resource in email GET link the action might be triggered without user interaction, "e.g. by a malware scanner, link previewer, or cache primer". To what degree this is actually an issue I'm not sure because many apis use GET regardless and it seems to work enough for them to continue doing it.

[Max Ong Zong Bao]

Hmmm.. Building good REST api is tricky and building API for internal or external API can be a nightmare.

I find that if they are using either OpenAPI specifications and related tools or Postman.

They are serious in API development work.

Lastly having example like Auth0, Twilio or Salesforce is really a good leader to copy their design concepts.

[Prahlad Yeri]

I had used non-standard methods like PUT and FETCH in a REST API app I'd created as a side-project some time back.

But now that I think retrospectively, its not really needed. You can simply use one POST method with "action" or something as a parameter corresponding to the REST action you want (such as create, delete, update or insert).

[Michiel Hendriks]

GET should never have side effects. It is perfectly fine to use as URL to unsubscribe or confirm things in an email but visiting this URL should always show a form to POST the confirmation.

[Boris Jamot ✊ /]

🤮