I prefer simplicity and using the first example but I’d be happy to hear other options. Here’s a few examples:

HTTP/1.1 403 POST /endpoint
{ "message": "Unauthorized access" }
HTTP/1.1 403 POST /endpoint
Unauthorized access (no json)
HTTP/1.1 403 POST /endpoint
{ "error": "Unauthorized access" }
HTTP/1.1 403 POST /endpoint
{
  "code": "UNAUTHORIZED",
  "message": "Unauthorized access",
}
HTTP/1.1 200 (🤡) POST /endpoint
{
  "error": true,
  "message": "Unauthorized access",
}
HTTP/1.1 403 POST /endpoint
{
  "status": 403,
  "code": "UNAUTHORIZED",
  "message": "Unauthorized access",
}

Or your own example.

  • Tanoh@lemmy.world
    link
    fedilink
    arrow-up
    1
    arrow-down
    5
    ·
    20 days ago

    The clown, but flipped with a success field. If it is true then command succeeded, if it false something was wrong and there should be an error field as well.

    HTTP codes should be used for the actual transport, not shoe-horned to fit the data. I know not everyone will agree with this, but we don’t have to.

    • bitfucker@programming.dev
      link
      fedilink
      arrow-up
      1
      ·
      20 days ago

      The transport is usually TCP/IP tho. But nowadays QUIC is trying to make it UDP. HTTP is specifically an Application Layer Protocol from OSI model

      • Tanoh@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        20 days ago

        What I meant was that if you are returning 404 for example when a user doesn’t exist. You can’t tell if the user doesn’t exist or someone changed the API to remove the endpoint.

        But forcing HTTP codes without a moment to think it through seems to be the new fad.