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.

  • @Tellore
    link
    English
    1119 days ago

    When consuming APIs you often want JSON in successful scenario. Which means, if you also have JSON in unsuccessful scenario it’s a bit more uniform, because you don’t have to deal with JSON in one case and plaintext response in other. Also, it sometimes can be useful to have additional details there like server’s stacktrace or some identifiers that help troubleshoot complex issues.

      • @Tellore
        link
        English
        119 days ago

        It’s ok for internal admin panels and their backends as there are no security concerns in this case.