• xthexder@l.sw0.com
      link
      fedilink
      arrow-up
      15
      ·
      10 days ago

      You can send 4xx errors yourself too. If the client needs to change something about the request, that’s a 4xx, like 400 Bad Request. If the server has an error and it’s not the client’s fault, that’s a 5xx like 502 Bad Gateway.

      The wikipedia listing of all HTTP codes is quite helpful. People also forget you can send a custom response body with a 4xx or 5xx error. So you can still make a custom JSON error message.

        • Eager Eagle@lemmy.world
          link
          fedilink
          English
          arrow-up
          9
          ·
          edit-2
          10 days ago

          A 2xx means success to its requester. If you have an error in step 6 out of 13 that breaks the resource action, you shouldn’t be returning a success.

          You might argue what to return and what kind of information to include in the response (like tracking numbers), but it shouldn’t be a 2xx and I don’t see how a misleading 200 would be more helpful than a 400 bad request.

            • Eager Eagle@lemmy.world
              link
              fedilink
              English
              arrow-up
              5
              ·
              10 days ago

              and to just send “Bad request” when it’s a good request - does not make sense

              That’s when you use a 5xx status, then. The client doesn’t care how many other services you reach out to in order to fulfill their request. A 5xx code also covers failures in other parts of the system.

                • Pup Biru@aussie.zone
                  link
                  fedilink
                  English
                  arrow-up
                  6
                  ·
                  edit-2
                  10 days ago

                  error codes aren’t about who’s at fault… you don’t send a 404 because it’s the users or the servers fault. it’s information… a 404 says something doesn’t exist… it’s nobody’s fault; it just is

                  a 4xx says the request, if tried again without changes or external intervention, is unlikely to succeed

                  a 5xx says the request might have been fine but some other problem that you can’t control occurred so may be retried without changes at a later time

                  these are all standard things that are treated in standard ways by generic HTTP libraries… look at, eg axios: a javascript HTTP library that’s often thinly wrapped to build API clients… a 200 is just passed through as success, where 4xx and 5xx will throw an error: exactly what you’d want if you try to retrieve a non-existent object or submit a malformed payload…

                  this is standard behaviour for a lot of HTTP libraries, and helps people accidentally write better code - an explosion is better than silence for unhandled exceptions