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.

  • asudox@programming.dev
    0·
    2 months ago

    Is the last one real? Has any sane dev made something like that monstrosity? It’s not like the others are any better, but who would ever think of doing the last one and why?

    • FourPacketsOfPeanuts@lemmy.world
      1·
      2 months ago

      I have worked for financial institutions that have variations of the last one. If I saw it I wouldn’t even blink. Semi realistic reasons might be:

      Status attribute - because the project is using the base library of [project whatever] which was the brain child of eNtErPrIsE aRcHiTeCt whose hands on skills are useless and the off-shore dev team who assigned [random newbie] because that’s who was available at the time. They used a status attribute because they didn’t know how to get the status of the http response. No-one with budget control is interested in hearing about technical debt at the moment. Everyone has to use it now else the poorly written test classes fail.

      Message code: because “we need codes that won’t ever change even if the message does”. Bonus points if this is, in fact, never used as intended and changes more frequently than…

      Message: “because we still need to put something human readable in the log”. Bonus points x2 if this is localised to the location of the server rather than the locale of the request. Bonus x3 if this is what subsequent business logic is built on leading to obscure errors when the service is moved from AWS East Virginia to AWS London (requests to London returning “colour” instead of “color” break [pick any service you never thought would get broken by this]).

      I have seen it all etc