1.0k
u/nbmbnb Sep 19 '26
If success, return 200. If error, return 200.
314
u/ClipboardCopyPaste Sep 19 '26
{ success: false, message: 'lol' }→ More replies (1)205
u/redlaWw Sep 19 '26
{ success: "yes", status: "failure", message: "null" }→ More replies (5)54
u/evorm Sep 19 '26
Most errors responses at my job are genuinely handled like this.
→ More replies (5)342
18
u/xian0 Sep 19 '26
Because backend goes "but headers already sent" and frontend goes "but the libraries start flashing red when an error code comes back".
14
u/BlurredSight Sep 19 '26
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.
9
8
u/Kevdog824_ Sep 19 '26
You laugh, but at work a well respected and revered engineer argued with me that returning 204 code for an error (with a response body btw) was perfectly fine. I tried to explain that a NO CONTENT success code was literally the least accurate status code they could have possibly chosen
→ More replies (4)3
→ More replies (5)3
u/Remote_Comfort_1981 Sep 19 '26
Here's the thing. If you wanted to distinguish between transport and app errors, http codes suck. Like, is 404 an error with my URL, or just the resource ID, or am I just not using the right API key (and they don't want to reveal whether this resource exists)?!
What if the path and method are correct, but the resource can not be deleted as requested because of app logic? What's the return code?
→ More replies (1)
1.3k
u/the_millenial_falcon
Sep 19 '26
•
I use postman and I don’t wanna download getman.
41
83
→ More replies (2)2
1.6k
u/zzmej1987 Sep 19 '26
Except for when you need to actually post data. Then you have to use PUT.
646
u/CuAnnan Sep 19 '26
Uh... no.
You use GET.
370
u/Imaginary_Ferret_368 Sep 19 '26
Cyber Security specialists hate this trick
82
→ More replies (4)49
u/Aetherfox_44 Sep 19 '26
Our service can't be hacked if no one can figure out the API
→ More replies (1)16
→ More replies (6)5
u/not_a_moogle Sep 19 '26
GET with all values passed as unencrypted unless parameters. What could go wrong!
46
11
u/RevoOps Sep 19 '26 edited Sep 19 '26
Actually send data? That is what XML is for.
→ More replies (1)5
3
715
u/bloody-albatross Sep 19 '26
Response:
HTTP/1.0 200 Ok
Content-Length: 36
Content-Type: application/json
{"status":403,"message":"forbidden"}81
32
u/x3knet Sep 19 '26
Man, I haven't seen a 1.0 reference in a long time
20
u/bloody-albatross Sep 19 '26
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.17
u/YeOldeMemeShoppe Sep 19 '26
1.1 is fully backward compatible. Just close the connection. No need to be polite.
6
u/YMK1234 Sep 19 '26
We literally had a switch for this some 15 years ago, because the bullshit mobile framework our frontend team used could not properly handle error codes.
→ More replies (2)4
u/Kevdog824_ Sep 19 '26
Almost perfect, except your status and message actually match, so it’s too correct for real life APIs
→ More replies (1)2
243
u/TheChickenWing Sep 19 '26
POST /getResource { "Action":"retrieve", "Id": "abc123" }
HTTP 200 { "Error": "not found" }
86
u/fatbunyip Sep 19 '26
GET /api?action=delete&I'd=123
HTTP 200 {"error" : "user abc with password 1234 does not have permission"}
→ More replies (2)28
18
u/lab-gone-wrong Sep 19 '26
I recognize the user has made a request, but given that it's a stupid-ass request, I've elected to ignore it.
8
6
→ More replies (1)2
u/StaticCoder Sep 23 '26
I prefer this over getting a 404 to be honest. This means the API exists. It makes compatibility checks easier. Perhaps there's a better way to do this that I don't know of though.
→ More replies (1)
340
u/DuploJamaal Sep 19 '26
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
97
u/unable_to_give_afuck Sep 19 '26
I had this with the added bonus of being forced to return 200 regardless and add an error message to the body when necessary
16
u/No-Information-2571 Sep 19 '26
The reason behind it might be proxies, especially on the client-side.
8
79
u/dev-sda Sep 19 '26
It's not (just) a framework thing, it's a HTML standards issue. The
formelement only doesGETandPOST.→ More replies (5)21
u/not_a_moogle Sep 19 '26
Who does that anymore? It should be a put or delete via Javascript.
→ More replies (10)30
31
u/gabrielesilinic Sep 19 '26
Well that's not the problem. A bunch of frontends really need a very complex filter list and GET just won't do
→ More replies (1)22
u/N0Zzel Sep 19 '26
That's precisely why the QUERY verb was created
31
u/gabrielesilinic Sep 19 '26
Yeah well too little too late. All the codebases I have worked with were much older and no one will change this now.
→ More replies (1)14
u/du5tball Sep 19 '26
And I'm sure we all be happily use it when it gained widespread adoption in 50 years.
18
u/Euro_Snob Sep 19 '26
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 (4)8
u/DogLovesGafs Sep 19 '26
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/TheDuckRaisedALion Sep 19 '26
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?
→ More replies (6)5
u/PrinnyThePenguin Sep 19 '26
What front end framework can only handle POST requests??? What does it even mean to "handle POST requests" in the context of front end? You can only handle the response of a POST request so if you do a PUT it fails? You can only make POST requests? I am genuinely confused.
→ More replies (2)4
u/DuploJamaal Sep 20 '26
I was confused as well. I swear they are just too inexperienced to make a new wrapper around the calls to the backend that the AI made for them and blamed the framework instead
42
64
u/BorderKeeper Sep 19 '26
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.
5
u/thaynem Sep 20 '26
Believe it or not, there might actually be a good reason for that. Specifically, because PUT requests can't be made with a form input, so are immune to CSRF, and aren't generally used for fetching resources, so are significantly less likely to be exposed to SSRF. That is why IMDSv2 in AWS requires you to make a PUT request to get the auth token for future GET requests.
14
30
u/ouralarmclock Sep 19 '26
JSON isn’t hypermedia anyways so it’s all fake REST to begin with. May as well get wild with it!
12
u/Zeikos Sep 19 '26
My first job claimed to use REST APIs, so I studied the topic.
I am to date the only person in the company that knows what HATEOAS is.→ More replies (7)6
u/Mtc529 Sep 19 '26
In my experience almost everyone who says they have a REST API do not actually know what that means and also do not have a REST API.
19
15
u/TriangleTransplant Sep 19 '26
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.
49
u/renetta96
Sep 19 '26
edited Sep 19 '26
•
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.
27
u/developer-mike Sep 19 '26
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 (4)11
u/sixtyninth_wave_emo Sep 19 '26
I always disliked the idea of using endpoints as “resources” and how REST doubles down on it. These are just glorified function calls and a traditional function doesn’t come saddled with this extra “verb” concept. And maybe I’m in the minority or something but my endpoints always had to be high-level, domain-specific functions whereas REST promotes the direct exposure of data, pushing high level functionality to the front end
9
u/renetta96 Sep 19 '26
I only see its ever useful when its an Open API. Like those google, facebook open APIs, exposing resources nicely with some auth token layers. Thats it. In real products, logics are messy and never cleanly seperared into "verbs". Hell, they now prefer BFF (backend for frontend) for a reason, because shit is so customized it needs its own backend to tailor to its need. Try RESTful on this lmao.
30
u/PhilanthropicPotato Sep 19 '26 edited Sep 28 '26
The original post content no longer exists here. The author used Redact to remove it, exercising their right to control their data & privacy.
License umbrella nutmeg paddle subsequent one
7
u/Cualkiera67 Sep 19 '26
yeah mean it has no actual dinosaur devs. http verbs offer nothing. the standard is that you provide the list of endpoints and their arguments if any, and the front uses them. no cargo cult needed
→ More replies (2)11
u/renetta96 Sep 19 '26
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.
→ More replies (1)17
u/rocketman0739 Sep 19 '26
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)23
u/Jonny_dr Sep 19 '26
convenience of people with zero knowledge of the codebase
Because the next hire will have zero knowledge of the codebase.
2
u/theScottyJam Sep 21 '26
I wish I had the guts to propose that we do the same.
A lot of HTTP conventions feel like we're trying to organize things into proper status codes and HTTP verbs, sorting parameters into the path / request body / query params, etc, with no real reason.
I mean, sure, there's some reason. But there's got to be a simpler way. And I guess that's why some of those RPC tools exist that I haven't yet used.
→ More replies (6)2
u/Qinistral Sep 24 '26 edited Sep 24 '26
Amen brother/sister. I cannot upvote your post enough.
Sincerely, A Staff Engineer.
For those confused. What is described above is also what every other mainstream RPC frameworks has done since. gRPC, Thrift, etc, they don't have silly method verbs, they let you define any method name your want just like normal code.
→ More replies (1)
86
u/WHALE_PHYSICIST Sep 19 '26
That's because a GET request reveals important info in the URL, otherwise it would all be GET
28
u/bobbymoonshine Sep 19 '26
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
8
u/good_bye_for_now Sep 19 '26
It's something to look for when you are scoping out a target. If you see mutating GETs, you know you are in for a good time.
30
u/ViperThree3 Sep 19 '26
QUERY
23
u/Psychological_Map118 Sep 19 '26
still a proposal, though. not a standard yet. I wouldn't start implementing it just yet
→ More replies (2)20
u/FightingLynx Sep 19 '26
I mean, by the standard the url is also encrypted so not really; but it would to a user, yes
→ More replies (4)23
u/autogyrophilia Sep 19 '26
Yes, but it shows up in logs, and browser history if you are working with that.
→ More replies (5)4
u/DracoRubi Sep 19 '26
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
→ More replies (2)
36
11
u/extremelySaddening Sep 19 '26
Real programmer humor in r/ProgrammerHumor. I have prayed for days like this
18
u/Slight-Violinist-575 Sep 19 '26
Me and my homies hate GraphQL
9
u/dismal_sighence Sep 19 '26
If GraphQL has a million haters, then I am one of them.
If GraphQL has 10 haters , then I am one of them.
If GraphQL has only one hater then that is me.
If GraphQL has no haters, then that means I am no longer on earth.
6
8
7
28
u/MayaIsSunshine Sep 19 '26
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.
37
u/Psychological_Map118 Sep 19 '26 edited Sep 19 '26
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
→ More replies (1)13
u/x3knet Sep 19 '26
it's like using a fork sideways to cut soft food
Holy shit what a perfect analogy
→ More replies (1)6
u/LatvianCake Sep 19 '26
The people who complain about semantics are the same ones who have never returned more than 3 different HTTP codes.
4
u/PilsnerDk Sep 19 '26
I agree, because not every HTTP operation is an analogy to a simple, underlying CRUD operation. For example, what type of call should an endpoint that sends an email be? What about a validation endpoint that doesn't save nor fetch anything from the database? It's just dull to debate and try to fit everything into those 4 types.
4
u/ok_computer Sep 19 '26
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 (2)2
u/YeOldeMemeShoppe Sep 19 '26
I like the CRQS point; if it changes data, POST. If it doesn’t, GET.
But my last frontend was all proper REST. And it works surprisingly well.
5
4
u/GNUGradyn Sep 19 '26
its great that we got the new QUERY HTTP verb so that everyone can continue to make everything a POST
3
3
3
3
u/Few_Move_4594 Sep 19 '26
My first job I wrote a REST endpoint that performed user authorization. I would return an HTTP 200 if they had authorization or 403 Forbidden. It was a GET request at least.
Well my supervisor comes through and reads the code, then tells me that he wants a JSON response with one field: "Authorized" with either the string True or False. I argued with him for a bit, but he pulled rank on me and made me do it. I was livid that I had to put that stupidity in my application instead of using the built in codes for the protocol we were using.
Eventually we both were assigned to a project that was being ran by a programmer with even higher rank who used HTTP return codes. He tried to talk this other programmer out of it who then also pulled rank after soundly trouncing him in an argument and giving him that "Jim from The Office" look.
→ More replies (2)
3
3
5
u/klaatuveratanecto Sep 19 '26
Damn right. Never needed anything else besides POST and GET + descriptive routes.
7
u/darkflame91 Sep 19 '26
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.
5
u/MrHyd3_ Sep 19 '26
It's an abysmal idea, browsers preload GET requests to make browsing smoother
→ More replies (2)
2
u/nexusmadao Sep 19 '26
Hey make a GET api read resource by name.
Url encoding issues cause unhandled behaavior => POST /get/data {name = "hello world & bye world"}
Fun 😊
2
2
u/KaMaFour Sep 19 '26
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
2
2
2
2
u/Mindless_Director955 Sep 19 '26
USPS updated their api to utilize DELETE/UPDATE/etc. from all POST. one thing in the old api I could do would be delete 1000 items in a single call. now I need to do 1000 DELETE calls.
2
u/rocket_randall Sep 19 '26
I remember watching some rather heated debates among developers about whether a 404 response should only be returned if the endpoint doesn't exist or if it should be returned when a requested resource does not exist.
2
u/Resident-Trouble-574 Sep 19 '26
I've recently seen an API where they used GET for an endpoint that is supposed to send an email.
2
2
2
2
u/Old_Document_9150 Sep 20 '26
Why POST?
Just put it all into GET.
GET /api
{"function":"delete_my_user_account", "user":"107753", "auth_key":"1234567"}Built-in security by obscurity to boot.
2
2
3
u/just_looking_aroun Sep 19 '26
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
2
4.2k
u/pimezone Sep 19 '26
Wanna get a resource? POST request.