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.

  • huginn@feddit.it
    2·
    3 months ago

    Theory is fine but in the real world I’ve never used a REST API that adhered to the stateless standard, but everyone will still call it REST. Regardless of if you want it or not REST is no longer the same as it’s original definition, the same way nobody pronounces gif as “jif” unless they’re being deliberately transgressive.

    403 can be thrown for all of those reasons - I just grabbed that from Wikipedia because I was too lazy to dig into our prod code to actually map out specifics.

    Looking at production code I see 13 different variations on 422, 2 different variations of 429…

      • huginn@feddit.it
        1·
        3 months ago

        You missed the point:

        The original creator of a thing does not control the current usage.

        It’s analogous.

    • Lysergid@lemmy.ml
      1·
      3 months ago

      “Stateless” is not what “I” want, it is part of definition of REST.

      Can do != what spec says you should do. You can also send clown version from the post but don’t be surprised people will find it… funny

      Again, I’m not telling you are doing wrong. I’m telling you are mixing REST and RESTful web services