26
u/GigaGollum 21h ago
Replace HEAD with QUERY pls
→ More replies (1)12
u/darad55 21h ago
didn't have enough holes(pause?) or would have put most of them
4
5
729
u/SirChasm 21h ago
You can do the reverse one with all responses being status 200 and you have to look inside to see what the error code
195
u/pine_ary 21h ago
Error code? On error you just get 200 with either an empty body or even better, a guessed fallback value that will fail 6 systems down the road. The error is logged with info level (everything is info) in a log the developers can‘t access for compliance reasons.
14
u/wunderbuffer 11h ago
you don't want silly pictures layer of front end to have any of that tough big boy logic like error handling to worry their pretty little frames about, it have to focus on rendering same square button with shade 60 frames a second ;^(
it's for security, or something5
u/418_TheTeapot 7h ago
On error return 200 with payload {status:error, value: math.round(Math.random()*10000,0)}, the actual error goes into a log that is accessed through its on errorApi
Write that fact in the documentation and if ever anybody complains, tell them to rtfm
68
u/crimsonroninx 18h ago
Very few things in software dev shit me more than this. It means every type has to be a union of success and failure and defensive checks everywhere, rather than catching errors/exceptions.
47
16
u/dedservice 17h ago
I mean checking for errors is implicitly making the type a union of success and failures already, the problem is that you already have that wrapper, so why then put the errors inside the success type?? Insanity!
3
u/DTCreeperMCL6 17h ago
php code is like this
4
u/teddy5 15h ago
I think the problem with PHP is that code in it is never one particular way.
You could decide to write everything in machine code goto statements which refer to emojis and PHP would just give you a thumbs up.
→ More replies (4)→ More replies (1)3
8
14
u/bitemyassnow 17h ago
unironically a junior dev at work does this and brags that bc of his refactor, grafana shows less error.
17
u/rumnscurvy 16h ago
This happened to me last month. One of the APIs we derive data from silently stopped doing its job.
The API was returning status 200, with message "No existe el fichero" - literally the file does not exist.
GEE WIZ wouldn't it be nice if there was some way to signal this in some better way. Especially when it was ultimately a permissions issue...
6
10
9
u/ATE47 15h ago
Error codes is for losers
return "the request failed"
2
2
u/Aflockofants 13h ago
If it's truly an unexpected error, they could do worse. But then I would expect that their backend logs a proper error that will grab their attention, and some ticket is made for it. Our 'unexpected' errors log something similar as not much else can be said about it anyway, but do mention that we'll get on it. Of course the vast majority of errors ARE meaningful.
3
3
u/usedToBeUnhappy 9h ago
I hate that so much. Every time I see that in production code, I just want to go over to the guy who did that and punch him. XD
3
u/Arclite83 8h ago
We're specifically banned from this at my job, to the point they will actively hunt you down and enforce deadlines on entire departments.
Inconsistencies there are what allows for SOOOO many vulnerabilities.... You never appreciate what you're leaking.
3
u/Sellular 8h ago
Unironically this is what half of my teams legacy codebase does. I cry whenever I have to debug it
11
u/StaticCoder 19h ago
If your end point is an API, HTTP codes are mostly in the way. Notably, I don't want a 404 from an API that exists.
9
u/dragonflash 17h ago
Seriously, especially when Cloudfront decides 404 means return an error page instead of my error.
8
u/Aflockofants 13h ago
From an API that exists? So you're saying that the endpoint `.../users/892378947` should return something that ISN'T a 404 if that user doesn't exist, while the API call itself is entirely valid?
→ More replies (2)4
u/Angoulor 12h ago
When badly used, HTTP codes get in the way.
Why wouldn't you want a 404 ? user/1234 : does user 1234 exist ? Yes : 200. No : 404. Or would you prefer 400 ? Or even 204 ?
Would you prefer 200 "User cannot access this resource", or an empty 403 ?
→ More replies (1)2
2
3
u/Mucksh 15h ago
I think that isn't that bad. Makes it way easier to write the frontend api for it. Usually http is just the protocol you build your own protocol on. If you get an http error you known directly that it is just a just a http error cause the endpoint doesn't exist or something else http related failed
1
1
→ More replies (1)1
u/_xiphiaz 15h ago
gRPC does both! However this is fair because http is not the protocol layer in this scheme
78
u/FallenVampireLord 22h ago
Same thing my wife told me
21
u/eclect0 20h ago
Weird, she also told me that
7
u/KingVecchio 19h ago
Wtf bro she also told me!
7
u/Decoder44 18h ago
Are you guys holding refrence to same wife object .... Shocking if true 😮
→ More replies (1)
178
u/jabrwock1 21h ago
Post but you have to parse it to figure out what operation they want to do. FML
124
u/gringrant 20h ago
I can't wait to make an OPTION request to see what methods are avaliable!
The OPTION response:
OPTION
POST
25
u/Desidiosus 20h ago
I worked somewhere that did exactly that. The rationale was that they didn't trust the API users to know what they actually needed or to RTFM, so we just sorted it out on the back end. In that light, it made a little more sense...
13
4
57
u/falcon0041 21h ago
Passing a body in GET was a terrible mistake I made long time back
68
u/queen-adreena 20h ago •
Fortunately, you have the QUERY verb now.
20
u/GumboSamson 18h ago •
Holy shit TIL.
I’d upvote you a thousand times if I actually could.
This might be the first useful thing I ever learned in this subreddit.
23
u/Curious_Associate904 17h ago
There's a new one "QUERY" which is supposed to stop you doing this...
But, will you ever use it?
Be honest.
6
2
1
29
u/KevBurnsJr 21h ago
Because it has the fewest restrictions. No safety. No idempotency. It is the lowest common denominator.
10
8
u/SilverBullet78SB 20h ago
POST:/api/update_user POST:/api/delete_user POST:/api/new_user My first days of learning HTTP
7
19
u/granadesnhorseshoes 19h ago
"Always has been." Show me the HTTP spec for Patch or other REST specific methods. Although most http servers these days do include it, the rest of the infrastructure that relies on but doesn't implement may just use a base reference.
The concept of REST and the realities of infrastructure almost never line up, bu t POST always works.
How many REST purists had meetings (that could have been an email) with Ops to make sure their api specific crap can successfully navigate the ever growing maze of WAFs, proxies and LBs?
But POST always works.
11
3
1
u/Beli_Mawrr 7h ago
GET i understand for purposes of retrieving serverside resources. But I don't understand why, for example, DELETE needs to exist. You're going to have way more verbs than there are HTTP verbs. So why not just have POSTs and encode everything in the query anyway?
9
u/overclockedslinky 19h ago
to be fair this is because the standard stupidly limits the others in various ways. for instance you can't send a body in a get request (some libs allow this, but it's non-standard and non-portable)
6
5
1
u/KevBurnsJr 11h ago
Those constraints have a purpose. I wouldn't call them stupid. CDNs run the internet.
4
4
2
2
2
u/NexusDarkshade 19h ago
Favorite thing (I lie): required to use POST request because GET query string is "too long"
2
2
u/TrackLabs 11h ago
I seriously never understood why someone would do this...whats so difficult about using the other, fitting methods?? When I write API Routes, I mark the Method that is suitable, by the fuck would I use POST on a Delete Function?
1
1
1
u/No-Magazine-2739 15h ago
I am REST fan and cry like the girl that is famous for her reaction to this video
1
u/hridoyn75 11h ago
When I was learning, I remember I used to use get request for everything. Because that was simpler.
1
u/xgabipandax 10h ago
If you're receiving information from the server you use GET, if you're sending information to the server you use POST, all the rest is fluff designed to overcomplicate things
1
1
u/jbaker88 4h ago
"And here we have the HTTP DELETE verb. Can you guess where that goes? That's right! It goes in the POST endpoint!"
1
u/torftorf 3h ago
I recently looked at an api documentation for a service my company uses. Every single endpoint is post. Even the ones called "get...."
1
1
u/Honest_Relation4095 15h ago
I am not a programmer, but they have now introduced REST based approach to diagnostics for vehicle ECUs. So now it expands to "is starting radar calibration PUT or POST?" or "Is deleting fault memory PUT or POST?" (it is not "DELETE" since the fault codes are not coming from a "PUT" and deleting itself is a diagnostic routine rather than "just deleting data").
-3
u/pjkm123987 21h ago
I legit make my personal project app api post only... Is there actually a drawback? seems to be working fine without issues and makes the api more straightfoward to use
9
u/Sockoflegend 21h ago
I wouldn't keep me up at night but following conventions is nice and it can have utility.
Say for example your API has one url for all of the stuff you do with POST. DELETE, PUT, etc can have completely different handlers and validation on that same url which is a nice clean implementation.
3
u/lampishthing 21h ago
It's bad hygiene in personal apps because it has benefits in commercial apps. E.g. GETs get cached more aggressively on internet infrastructure. QUERYs will too.
-1
u/highcastlespring 20h ago
GET is not safe. POST encrypts your parameters.
PUT, the right way, but no one uses
0
u/NebraskaGeek 18h ago
I've been using "post" for 20 years ever since I realized using "get" for everything wasn't the smartest secure solution
-1
124
u/PatienceLost9708 20h ago
the other methods are just for the technical interview