780
REST my ass ๐Ÿ’ฉ (eviltoast.org)
submitted 1 year ago by to c/programmer_humor@programming.dev
102 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[โ€“] 17 points 1 year ago (7 children)

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

  • permalink
  • fedilink
  • source
  • hideshow 7 child comments
    •
  • [โ€“] 8 points 1 year 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.

  • permalink
  • fedilink
  • source
  • parent
  • [โ€“] 1 point 1 year ago (3 children)

    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".

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [โ€“] 4 points 1 year ago (2 children)

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

    That's certainly an unusual take. If you are a backend to HTTP and something throws a completely bogus URL out of left field at you, that's not by any means a backend error.

    I guess your take is that it might be some sort of usability issue or such because if 95% of clients try to hit the same non-existant URL, that probably means there's some reasonable expectation that you should do something about the URL. However that's relatively more rare a sort of 'invalid URL' scenario. The vast vast majority are some sort of scanners trying bogus crap, followed by an impossibly diverse set of typos and peculiar one-off assumptions that you can't possibly reasonably cover.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •