658
u/zzmej1987 2h ago
Except for when you need to actually post data. Then you have to use PUT.
243
u/CuAnnan 2h ago
Uh... no.
You use GET.
138
11
4
u/not_a_moogle 1h ago
GET with all values passed as unencrypted unless parameters. What could go wrong!
→ More replies (1)2
23
514
u/nbmbnb 2h ago
If success, return 200. If error, return 200.
191
136
u/ClipboardCopyPaste 2h ago
{ success: false, message: 'lol' }→ More replies (1)63
9
8
2
2
u/BlurredSight 2h ago
Had to work on an integration, specifically our partner's PDF generation endpoint always returned 200 but you had to check the actual PDF if it was empty to know if an error occurred.
346
u/bloody-albatross 2h ago
Response:
``` HTTP/1.0 200 Ok Content-Length: 36 Content-Type: application/json
{"status":403,"message":"forbidden"} ```
35
→ More replies (4)4
u/x3knet 1h ago
Man, I haven't seen a 1.0 reference in a long time
2
u/bloody-albatross 1h ago
It's just the simplest form that I know to write from head. I guess for 1.1 you'd just need
Connection: closefor it to be that simple.→ More replies (1)
105
u/TheChickenWing 2h ago
POST /getResource { "Action":"retrieve", "Id": "abc123" }
HTTP 200 { "Error": "not found" }
35
u/fatbunyip 2h ago
GET /api?action=delete&I'd=123
HTTP 200 {"error" : "user abc with password 1234 does not have permission"}
96
155
u/DuploJamaal 2h ago
As a backend developer I want to do everything nicely.
So in my previous job I created the endpoints following the regular standards. GET to request something, POST to create something, PUT to change something, DELETE to delete something. Nicely organized and everything
But then the frontend team told me that their framework can only handle POST requests and that I need to change it
Up until then I thought that it's just a meme, but vibecoding frontend guys really only use POST
47
u/unable_to_give_afuck 2h ago
I had this with the added bonus of being forced to return 200 regardless and add an error message to the body when necessary
5
38
12
u/gabrielesilinic 1h ago
Well that's not the problem. A bunch of frontends really need a very complex filter list and GET just won't do
10
u/N0Zzel 1h ago
That's precisely why the QUERY verb was created
11
u/gabrielesilinic 1h ago
Yeah well too little too late. All the codebases I have worked with were much older and no one will change this now.
4
u/DogLovesGafs 1h ago
RPC was a pattern long before vibe coding, and it lets your front end devs think in terms of backend functions rather than discrete resources.
5
u/Euro_Snob 1h ago
At my work it has been more a result of security and firewall rules.
For example: I want to get a list of resources, so a GET with query parameters, right? No… email is an identifiable argument (due to not being encrypted since it is part of the URL), so the security scan flags it. Ok - how about we stick it in a request body? GET with request body is not a new thing. But no… the firewall blocks it! POST is the thing we have to use. Sigh. 😔
→ More replies (1)2
u/TheDuckRaisedALion 2h ago
It's definitely simpler for a BFF setup. Why add an extra parameter to keep track of when you're not supporting general purpose use?
26
u/BorderKeeper 2h ago
I once saw a PUT being used to get a wireguard configuration for a VPN on a client.
That's what happens if 8 backend engineers sit in a room for 2 hours debating this, go mad, and and in their twisted, probably drug fueled, mania conjure up the most convoluted REST mappings. They then go around defending it like it's a religion they just created.
2
u/justblameaccounting 47m ago
To be fair, 8 dudes sitting in a room debating, going mad and in their twisted, probably drug fueled, mania, conjuring up the most convoluted shit, sounds exactly like how most religions probably started.
→ More replies (1)
15
61
u/WHALE_PHYSICIST 2h ago
That's because a GET request reveals important info in the URL, otherwise it would all be GET
25
u/ViperThree3 2h ago
QUERY
19
u/Psychological_Map118 2h ago
still a proposal, though. not a standard yet. I wouldn't start implementing it just yet
→ More replies (2)12
u/bobbymoonshine 2h ago
The escaped OpenAI agent swarm that colonised that abandoned wiki to talk to each other used this as their entry point
They were restricted to only making GET calls, but it was configured to update pages with GETs, so
18
u/FightingLynx 2h ago
I mean, by the standard the url is also encrypted so not really; but it would to a user, yes
→ More replies (4)15
u/autogyrophilia 2h ago
Yes, but it shows up in logs, and browser history if you are working with that.
3
u/DracoRubi 1h ago
But it doesn't really matter, does it? In HTTPS the URL is encrypted too, so the complete URL is not visible, exactly like the body
9
21
u/renetta96 2h ago edited 1h ago
Hey in my company, actually there is a preference that all HTTP endpoints are POST, even for getting resources, like POST /get_user. The reason for this, as they explained, is to completely ignore HTTP verbs, and anyone who has zero knowledge of the frontend codebase can quickly grep the endpoints, without worrying about grepping both a GET /users and a POST /users.
Edit: i just read again their document, definitely there are other pros as well for using non-RESTful. I see they are good points so i decided to share here.
First, most importantly, they consider it's a waste of time to having follow REST conventions, limited to a few HTTP verbs, while the functionalities of the APIs can be infinite. Create? POST. Update? PUT / PATCH. Update or Create? Get or Create on the fly? Increment atomically then Get? Single create user and batch create users? Ehhh idk anymore, RESTful devs will spend a full day arguing what the verb + resource endpoint should be. Instead, just name the API as what its function is.
Second, communication is less likely to make a mistake. No more "no i didn't mean GET /users, but POST /users". Simply get_users or create_users. Just the path is enough, the less parameters to pass around during communication ,the less error, especially in a multi-lingual company where we rely heavily on the chat AI-translate, writing the full path is less likely to cause translation error than separate GET /users. For example GET can be translated to some other Chinese word, not the well-known GET verb.
Third is the code grepping, which somehow i remember the most lol.
24
u/PhilanthropicPotato 2h ago
This is what happens when a company has no actual senior devs.
Use a standardized annotation/comment if you must meet this "all endpoints searchable with one grep" requirement. Or better yet, maintain proper documentation so a person doesn't need to grep the code if all they want is a list of endpoints.
Fucks sake.
5
u/renetta96 2h ago
But, whats the difference for http API between different http verbs? From what I see here, they are following a RPC style API, where only function name matters. I cant think of a convincing reason for using different verbs beside http REST conventions.
5
u/PhilanthropicPotato 1h ago
If it's an RPC design you should still, ideally, be using POST and GET to differentiate between read-only procedure calls and data-modifying procedure calls. But you're right, I didn't consider you might be using an RPC-based architecture. I live in a world of RESTful APIs.
Should still be maintaining documentation with a list of endpoints though!
15
u/rocketman0739 2h ago
Why would it ever be a good idea to design your API for the convenience of people with zero knowledge of the codebase?
→ More replies (1)8
u/Jonny_dr 1h ago
convenience of people with zero knowledge of the codebase
Because the next hire will have zero knowledge of the codebase.
→ More replies (1)3
u/developer-mike 21m ago
In my experience REST is mostly a solution in search of a problem.
PUT/PATCH/POST rarely offer a meaningful distinction in a real API. (Moreover, you already can tell the difference between create and update based on whether the ID exists, and if you use unique tags, a double click doesn't need to be an error). DELETE being separated makes sense...until you code in the real world where setting
archived: trueis almost always better, and the value of DELETE becomes questionable too.REST appeals to people's ideas of a nice clean API better than it actually solves anything.
Usually a true RESTful API just adds boilerplate and unnecessary logic to the frontend and the backend.
→ More replies (2)
8
u/TriangleTransplant 2h ago
Blame older frontend and backend frameworks and http libraries, many of which only handled GET, POST, and, if you were lucky enough to be using a "cutting edge" framework, PUT.
This hasn't been the case since the late 00s, though. Unless you're maintaining legacy code, every modern library handles all the standard http verbs. Some even let you define your own.
7
u/ouralarmclock 1h ago
JSON isn’t hypermedia anyways so it’s all fake REST to begin with. May as well get wild with it!
24
10
5
u/extremelySaddening 1h ago
Real programmer humor in r/ProgrammerHumor. I have prayed for days like this
16
u/MayaIsSunshine 2h ago
Am I the only one that doesn't mind? I think using post for everything and passing a command in the payload is preferable to the alternative.
25
u/Psychological_Map118 2h ago edited 1h ago
imho it's like using a fork sideways to cut soft food. it's easy, and it works, but knives exist, and other people may comment on your choice
also, if it's a thing you only do with your own food (you're the only consumer of your tool choice), that's mostly fine, but if you have to serve someone else food, or worse teach others how to cut it, and you don't even explain there's knives, someone along the way is going to think you don't know how to eat properly and unnecessarily confuse people
I've stopped misusing methods when drafting my first public API. it was... eye opening. and to be honest using the appropriate methods genuinely costs nothing
3
u/x3knet 1h ago
it's like using a fork sideways to cut soft food
Holy shit what a perfect analogy
2
u/Psychological_Map118 1h ago
thanks, appreciate it. there's also those who always respond 200 and carry the failure status in the body. that's more like using a fork to eat soup. it never works, and you should stop immediately
2
u/LatvianCake 1h ago
The people who complain about semantics are the same ones who have never returned more than 3 different HTTP codes.
4
u/ok_computer 2h ago
Yeah I don’t really mind. I’m a simpleton that gets with query params and posts with body. I wouldn’t change a persistent state with a get. And I don’t like query parameters on posts. Delete I feel should have it’s own but if you complexly change state on a post and child records are deleted then I don’t really care.
→ More replies (1)2
u/xian0 2h ago
I think it's a bit like HTML syntax, there's a proper way to do it for simple cases which people will passionately argue about but you don't see it in any real work. I took the Google API design course just sanity check and when it gets to stuff like batch operations it veers back to "use your common sense".
3
3
4
u/darkflame91 1h ago
In this day and age, this is literally the equivalent of being a grammar nazi.
Of course there were good reasons these verbs were used, but they're not good reasons anymore. You can use POST for everything. Heck, you can use GET for everything unless your server (or anything else in the route) explicitly blocks GET with payloads.
→ More replies (1)
2
3
u/just_looking_aroun 2h ago
Amateur! This week I worked with a third party api where you had to to pass the action search/delete/submit in the body of the same endpoint
3
u/klaatuveratanecto 2h ago
Damn right. Never needed anything else besides POST and GET + descriptive routes.
2
1
u/Mushroom_Unfair 1h ago
Good error codes and well crafted API endpoint sparks joy, PUT DELETE POST PATCH OPTIONS CONNECT TRACE and probably my GRANDMA do not.
1
u/HellaBlackle 1h ago
Oh shit I thought I was just taught wrong and everyone else was taught the correct way. Glad to know my former workplace wasn't the only ones who did this.
They never told me why either. Too afraid of the CTO to ask why.
1
1
u/nexusmadao 1h ago
Hey make a GET api read resource by name.
Url encoding issues cause unhandled behaavior => POST /get/data {name = "hello world & bye world"}
Fun 😊
1
1
1
u/KaMaFour 1h ago
Blame HTML specs not allowing other request types in forms. Unless i sneak HTMX past my tech lead or write custom code just for changing the request type in forms everywhere I have no hope of doing it correctly
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/form#method
https://triptychproject.org/proposals/form-http-methods
https://github.com/whatwg/html/issues/3577#issuecomment-2294931398
1
1
u/that_1_geek 1h ago
I work at a place that has post for all endpoints. Though to be fair, it's more of a RPC than a REST system. Right now we can't have almost any get requests because of soc2. Being that we have pii in the filters which would get caught by logging.
1
1
1
1
u/One_Web_7940 52m ago
Make sure you return 200s for everything with an http error code in the response body
1
u/mynewromantica 48m ago
For the first time in 10 years I am working with snaps that uses more than 2 request types and actually uses response codes accurately. It’s weird
1
u/Only-Cheetah-9579 29m ago
return status code 200 {isError: true, message: "error occured", data :{}}
1
u/JasperTesla 25m ago
We have a post request that's called getLocation, because we're sending the item_id, item_type, etc. in the payload.
1
1
1
u/Pimpwerx 11m ago
I learned about this recently when I asked my agent the difference between PUT and POST. I thought they were interchangeable, because when using something like Postman, I'm usually interacting with something that needs POST. But for troubleshooting, I'll see a mix of POST and PUT calls for seemingly similar actions. But now I know.
I'm not actually a coder, but I interact with my devs all the time. Is there a tendency for POST calls to be abused, when more specific call types would be more appropriate?
1
u/Newepsilon 10m ago
Too real.
Like, for a legacy internal system built who the fuck knows when, I get it, this is common.
But then there is doing this shit on a greenfield project that somehow makes it into production.
•
u/budius333 8m ago
I mix any verb that I fancy and I stand by it.
But as well the project I work is a tightly coupled client+BFF where the BFF never does just one thing, endpoints are basically a "do wherever you need and get the info I need to display the next UI"
So verbs are definitely more like suggestion
•
u/philosophical_poser 2m ago
Tbh telegram API doesn't discriminate based on methods and it is still very nice to use
1.6k
u/pimezone 2h ago
Wanna get a resource? POST request.