Been having similar case with dev teams who have coded every error to be 500. User typed the wrong URL? 500. User tried to access a page without logging in? 500... Makes detecting real errors a pain

[–] homura1650@lemmy.world 1 points 56 minutes ago

I would argue that in your application, a wrong URL is a sever error. That error being improper handling of a client error.

I'm not a web dev, but had a similar problem with a niche compiler I used to develop.

We were pretty good at validating invariants at the mid and back-end. This meant that most user errors got reported as internal errors. Generally, these errors were good enough that users were able to get used to reading them and fix their code.

It was next to impossible to actually get users to file bugs about this. Our internal error messages started with a banner that read "THIS IS A BUG IN . PLEASE REPORT TO ". Despite that, whenever we actually got a bug report, it would inevitably start with "I'm pretty sure this isn't actually a bug in the compiler, but I can't figure out what I am doing wrong in my code".

[–] Blackmist@feddit.uk 3 points 1 hour ago

And on the other side of this are JS devs that check for neither error response codes or error messages, and write an error into their own data as if it's the result they were after.

Always fun to see GET /orders/{error : "invalid branchID provided"} in your logs.

[–] whoisearth@lemmy.ca 26 points 17 hours ago (1 children)

Fun story close to a decade ago we were attempting to upgrade our batch scheduler called Tidal to version 6x which had a RESTful API.

One of the reasons we dropped the product was because we were getting 200 status codes meanwhile the output was a java dump of an error message.

They were adamant that this was an us problem, no matter how much I tried to explain to them with numerous links explaining to them that if something has a 200 status code that should mean things worked.

They argued that the 200 meant we were hitting the API fine. We would have to write code to read the return for if it was a error or not. I still don't think they understood how stupid they were, even all these years later.

[–] jj4211@lemmy.world 10 points 4 hours ago (3 children)

I have had that argument repeatedly with people. People insisting that HTTP error codes are "transport layer" and it's "wrong" for an API to hijack them to report "application level issues".

No, the whole point of "REST" was to map application semantics to HTTP in a way that actually normalizes some things like error handling and expectations around whether an operation could be expected to be idempotent and make the namespace navigable.

At one point my work announced a person who was an external hire to be the 'API genius' to set my company straight. He came from a super reputable well known company so of course he just the smart guy to fix our technical mess. He had sent a message saying that he had reviewed the teams API and concluded they were not restful. I had a glimmer of optimism, that someone recognized as authoritative would call the RPC style HTTP usage that always returned 200 and steer toward sanity, or at least honesty. No, his feedback was that was all fine, but REST does not use JSON, REST uses Protobuf, so they need to change to Protobuf to claim to be REST. Of all the what the hell I could have predicted, that one was not in my book...

[–] RedFrank24@lemmy.world 1 points 2 hours ago (1 children)

A real "API Genius" would be complaining that your API doesn't include HATEOAS, even though I've never once seen an API be used in that way, and few of the big tech APIs actually use it even though they call their APIs RESTful.

[–] jj4211@lemmy.world 1 points 1 hour ago

My particular project did embrace HATEOAS, just other teams did not.

[–] enumerator4829@sh.itjust.works 1 points 4 hours ago* (last edited 3 hours ago)

The number of people talking about REST without having read the wikipedia page is astonishing. Roy Fielding’s dissertation on the subject might be of interest, but that’s from 2000 and absolutely not webscale.

(Edit: /s if that wasn’t immediately obvious)

[–] UpperBroccoli@lemmy.blahaj.zone 1 points 4 hours ago

The quote "brimming over with wrongability" comes to mind.

[–] ipkpjersi@lemmy.ml 5 points 14 hours ago

Oh no... this brings back memories LOL

[–] TomasEkeli@programming.dev 41 points 1 day ago (6 children)

Please, please, please, PLEASE return error-codes and problem-details.

Here's the RFC: https://www.rfc-editor.org/rfc/rfc9457.html

[–] HugeNerd@lemmy.ca 20 points 18 hours ago (1 children)

[–] blarth@thelemmy.club 10 points 17 hours ago

Nightmares.

[–] darvit@lemmy.darvit.nl 5 points 19 hours ago (1 children)

This looks so over-engineered. Most of the time you only need an error message. Make the message clear enough so that it can be shown to the end user.

[–] TomasEkeli@programming.dev 2 points 4 hours ago

Why even use HTTP, when you can just send bytes directly over the physical network card, right?

Because standards make it better for everyone. You've no idea when, who or in what context the error will happen or be received by.

It takes so little to return ProblemDetails, and improves the experience of devs using your API so much. Just do it. Stop thinking up edge cases and faffing about with excuses. Do it.

[–] douglasg14b@lemmy.world 0 points 12 hours ago (1 children)

Counter argument is that error codes and problem details can be used by attackers to reverse engineer and find exploitable parts of a system.

Within reason anyways

[–] Feathercrown@lemmy.world 9 points 11 hours ago

So can a 200 response with an error description

load more comments (3 replies)

load more comments