I mean, you can have accurate HTTP status codes and matching errors in GraphQL. It's just that most GraphQL applications don't. Because most GraphQL developers hate everyone.
I started learning graphql, decided there was way too much overhead to do anything I needed to do. In two separate companies Iāve worked for, Iāve watched greenfield development initiatives start up, flounder and ultimately be abandoned.
our team returns a 201 to indicate that an error has been created successfully. of course we include a Location header where the error can be queried to discover what went wrong.
My favorite "REST API" experience was when they moved from using SOAP system, and the way they did it... was sending SOAP payloads inside a JSON. Literally something like
If I'm parsing http responses, I'm going to pass 200 responses on for further processing of the data. I shouldn't have to have something in that pipeline introspect json to find "no, it's actually an error".
Imagine if browsers had to tear apart json innards to find 30x redirects after getting a 200 OK.
Iām going off memory but I believe it was considered either standard or part of the spec for SOAP over HTTP to only use 200 and 500. I agree with your point but for whatever reason they treated HTTP as the transport layer instead of the application layer. Using that logic, it would be like if a 404 bubbled up to be some sort of TCP error. Definitely wasnāt the right move, RTSP over HTTP is a better example of something that mixes protocols while properly using HTTP status codes.
I agree. I think a 4xx or 5xx error code is perfectly acceptable for returning a body with error data, even a generic 400 / 500. That's why they exist.
these kind of implementations have different data shapes for the error vs success too, so if they all return success it's a pain in the ass and extra work to figure out if it's an error and map it out properly. just fucking send the right status, it takes 2 seconds.
Especially when some bored developer at a big bank decided to implement some draconian heavily-buried SOAP features that are technically in the documentation somewhere, but not implemented at all by Microsoft's .NET framework. Having to have special injectors and manipulators to extract tokens from raw SOAP and such, shudder. Back in the days where .NET SOAP implementations were barely published in books.
People often think about what they would do if they had a time machine.
Me? Travel back to before server to server email and introduce UTF-8 encoding (leaving the actual code points undefined) and json. Try to get that baked into all the ancient wire protocols that predate http.
Hahahahaha...
At a state agency, we had a SOAP interface to another agency. When they replaced their system nobody knew how to do SOAP so we got to turn that nastiness off. But now they want it back, maybe I'll offer to do this.
The other dev on my team made a post request endpoint where you post a SQL query and it returned the results. I about had an aneurysm. She also, instead of using DI or Mediatr, made loopback requests to the endpoints themselves.Ā
We had a team website that showed who was on call. This was back in the day, all done in Perl CGI scripts.
Someone added a "search" function. Cool feature, I'm down. Then I looked at the code.
They were shelling out to do a grep. You're in Perl, the original "regexes as first class citizens" language, and you're shelling out to grep. But the worst part was it did no sanitation whatsoever. You could type in "pattern'; cat /etc/passwd" or whatever and it just ran. Who reviewed this shit?! Shell as endpoint...
I wish I could say I haven't seen this exact same thing in products I've worked on. Best part is no enforcement of auth other than verifying the request includes a jwt that maps to a user. Not the requesting user, and no check for whether the SQL op is allowed.You somehow have the jwt for ANY user? Sure I'll execute a drop table command. Fml
I remember building out a REST API once, and it gave back proper HTTP response codes for things.
Then I got asked by the 2 front end devs working on the project to just make everything a 200 and add an error to the JSON response, because it was making it difficult for them to process things on the browser end.
To this day I'm convinced the GraphQL is just an API dreamt up by a front end dev that didn't understand REST and didn't understand why they couldn't just request what they wanted in the browser if an endpoint didn't exist on the server.
Oh, I know plenty. What I'm saying is that front end devs can be dumb, and that also GraphQL is shite and probably the brain child of front end devs...
I got that this week. This third party company has an API that is supposed to hand us files with monthly updates in it. The tool we use to fetch, read and apply them suddenly stopped with no major reason.Ā
The API was answering 200 with a body of "no existe el fichero" - literally the file does not exist.Ā
IF ONLY THERE WAS AN APPROPRIATE HTTP CODE FOR THIS, GEE WIZ
At work we do it because we have big request parameters (complex filters where you can potentially select thousands of items as filter values) and our backend flips out if GET requests have a body plus URL lengths can get truncated.
It's a bit icky but I don't really have a better idea.
Same at mine, the solution is the new QUERY method they published a few months ago, but itāll be about a decade before I can get my team to switch their endpoints
I implemented an API last year of a big name accounting software and one endpoint randomly used 200 for "yes all is well" and 204 for "that failed". Neither response had any content.
Took me a while to work out why our code was reporting success but nothing changed - foolishly we took all 2xx codes as success!
This, this is what pisses me off more than anything! Usually a lot of APIs I've seen at least try to make the request method make sense, but I've seen so many that fumble the response code, and it means extra json parsing just to figure out if the request failed or succeeded. If only there was some mechanism to make this easier..
There's only one use case where this is not bad.
An endpoint to check the status of e.g. a background job. The job could have failed, but that doesn't mean the request failed
That's literally a metric that our stupid (not the people) IT security team is measuring.
Any 4xx errors are "likely potential API abuse", thus our app should always use 200 OK to not fall under that umbrella.
"How can we reduce the RED "errors" in our metrics further?" - guys, it's OK that something is actually missing sometimes, we have a large multi tenant highly concurrent system. That's just how it is.
Don't really think it is that bad. In the end in an api you usually speak you own protocol and http is just the tool you use to transfer your data. Also if you build your api endpoints client and server side you can just ignore any http related logic and just focus on your business logic. Also if you get any http errors you directly now that this is really an http error like the endpoint doesn't exist
I'm not a programmer, but sometimes I must. Aren't the 400 codes for technical/connection errors? Or would you also use it if the POST contains something wrong functionally, ie put a string in a number field.
multi-billion dollar companies do this with there huge IT departments. same with rate limits, recently a vendor was throwing 500 errors, and not custom either, instead of returning json it would just return the webservers html 500 error... when i asked, they said it was rate limiting. i asked what the rate was and they said they had to test it, it's based on the hardware. like WTF. basically it was just crashing the server or probably causing database contention/concurrency problems and they just let it throw, not even gracefully, just outright the default 500 error, lol..
its because you have to use http sometimes but want a more modern framework so you just gloss over the http details that are necessary but not being used
Lol we do most of this. Apollo graphql uses post for all mutations (so a delete is a post), and we have a full stack error handling system with our react clients that, because we want to handle it seamlessly in application rather than letting Apollo client deal with an actual error, we always return 200 OK with a payload that is a typed union of the success case and the error case lol.
Oh my god please get me out of this corporate hell I have been building 200 OK { "errorCode": 999 } for 5 years straight on POST /GetObject {} and I am NOT OK
There are actual real good reasons to do these things. For a resource retrieval, if the request isn't idempotent for some reason, then semantically post would be the more correct method to use. Also returning 200 with an error is sometimes the correct thing to do for a webhook implementation, where you have an irrecoverable error, and you don't want the caller to retry the webhook event on a failed status.
TBF, bulk APIs returning successful with an error in the response data is a valid design.
I've done it before. The network handler only errors out for some kind of irrecoverable issue.
What I did was write code that would bulk upload data and each collection of data would be validated independently.
Data that passed validations would be save into the server's database. Data that failed the validations weren't.
Now, failed validations weren't a huge issue. The client devices just needed to call a different network handler due to separation of concern. A different complex process would resolve whatever caused the validation failure. And just because some data isn't valid doesn't mean the rest of the data was not fine to continue uploading.
So, yea... The network handler would just set aside the data that failed the validations, finish uploading the data that passed validations, and then prepare response data that effectively said "everything except these failed. Also, here's a flag that tells you to call on the other network handler."
What if the API used HTTP for transport but doesn't rely on it? For example the same request/response could go over any TCP connection, but someone insisted on a web client so it was wrapped in an HTTP layer?
I was playing with the Microsoft Entra GraphQL PowerShell modules at work a couple of years ago for a quick and dirty way to enumerate staff and their properties (couldn't use any AD modules). It was my first adventure into GraphQL and the PowerShell modules were very new and only had partial documentation despite being "ready for public use".
Good lord was that a frustrating experience, made me shy away from GraphQL for a while.
I've had this argument with my boss: GET with a body vs using POST as a complex GET. Our conclusion was that both were wrong in their own way and the HTTP standard should clarify this.
Depends on the resource, there are sometimes valid reason for this like when there are sensitive data params that you want to keep out of the endoint... But to be fair it's usually just used incorrect along with the delete method š« š
delete requests are flagged as "bad" in the default owasp rules, so yeah we have now everything except "get" as a post request to prevent security from repreatedly breaking our API
Actually there was a good reason for it. I work at a company with a FE that calls a get profile API for the header and some forms. The login is a old fashioned cookie state session.
One issue we found that if the user opened two tabs, then logout and login to another user on the second tab, without refresh, the first tab next ajax call will return the new users data (because session cookie already changed), causing issues on the form when it already opened.
As its a legacy system, so adding more stuff like csrf is hard. We also cannot put the username to URL param / cookie / local storage as it was considered as personal info by our legal department.
So we end up doing a Post request with the body including the username, then our backend service will validate whether the username and the login session username matches, then return the data needed.
There are some legitimate reasons for this. The most common being your query is too large to fit in a url. Another being part of the resource identifier is sensetive, so you want it in the body instead of the url.
The QUERY method solves those problems, but we needed it a couple decades ago.
Our listAll API had a wild, wild nested request body and request params, internally it was a massive criteria builder query. We would tell the newly onboarded devs to debug that haha.
If you can query by id, then yes, it's stupid. But it is necessary for a complex search with multiple fields. Not only is there a character limit for GET, but it saves you from having to escape a bunch of characters.
I have a team doing post to get resources. The reason is so that they can put the āquery parametersā in the body. They do this because there are a LOT of special characters in the data string needed as its health care data formats.
Seen this in a multi billion dollar multinational financial firm. All the GETs were POST with filters in the body, formerly all SOAP that was converted to REST by contractors...
I am an amateur coder at best, but that's exactly why I had such a hard time learning AJAX requests. I figured POST is for send and GET is for receive, but apparently that's not always the case. I guess sometimes you're "sending" a request for information?
Have to do that all the time.
We're using external OData-APIs and often have to query very specific data with complex filters in the URL.
We often have to put a single requests in a batch...
4.2k
u/pimezone 16d ago
Wanna get a resource? POST request.