I hate API like this
I hate API like this
- This is Microsoft.
- He returns Webhook success with a code 200 and plaintext 1.
- He returns Webhook failure with a code 200 and a string tells its endpoint returned error 400.
- the string didn't tell what exactly the error.
- Don’t be like Microsoft.
EDIT: Got a few details wrong since this happens a few months ago and this meme used to be on r/ProgrammerHumor. Also the proof: 
It's hard when you hit an endpoint that hits another endpoint, because technically the first request IS a 200. No right or wrong way as long as they are consistent and document it clearly imo
I my experience you then send a different error code to help developers know that right away. Really if there is nothing the developer could do it should be a 500 server error. The server did in fact error.
If the developer should have done something different then translate it to an appropriate code, 400 bad request or something
In this case I like to return a 502.
Great time to implement a 7XX code: https://github.com/joho/7XX-rfc
739 might be a good one
Working with Microsoft's APIs is akin to trying to navigate a maze of barbed wire with a blindfold on
After working few years on a complex web application, I am starting to feel this style. Doing RESTful APIs for anything else than dead simple CRUD is pain.
It's similar to how I now often avoid throwing errors in my code, and instead return a 'results' object that could potentially have an error or a success. It often forces you to test and think about the non happy path more thoroughly.
Exceptions actually have a huge performance hit, you should only use them in a HALT EVERYTHING IMMEDIATELY situations and never in anything that could be called repeatedly. We have refactored few of those to be 10-100 times faster by just returning success: false instead of throwing and catching exceptions.
Or when you hit an API and the error message comes back as html instead of json.
Failed successfully.
The quality of Microsoft APIs is legendary... if you just take a minute to study win32, you will be always glad that those webserver responses are the kind of shit you have to deal with.
But to be fair, this looks exactly like a well designed API that somebody pushed behind a corporate firewall.
Wait til you hear about graphql..
What don't you like about graphql error handling? Whenever I've made a graphql api, I use the default errors as unhandled/system errors and payloads return handled error types.
It's a bit more boilerplate to wire up, but I find it smooth to build and use
Yes, but actually no.
Yeah, that's a pain. I'm probably lucky to only have experienced this once.
Yeah, typical on .net too. I just have a middleware and turn it into proper REST. Though all the error messages are usually like 'something went wrong'.
Wait, do you know if this still happens?
I have a ticket in our backlog to investigate similar issue with Teams Webhook reporting success but not posting anything.
None of us wanted to look at it so been in our backlog for a whilr
Yep, this still happens
There's a video somewhere by someone... Returning a blank document instead of an error code is sometimes a QoS decision. Clients won't make a new request without the user intervention, so whatever resource that's bottlenecked has time to catch up
Since it's been months, I haven't checked... Will possibly take a look later
Sometimes it is because some monitoring tools are set to generate alert on certain frequency of 4xx / 5xx errors
nice plain text response 🤦