this post was submitted on 30 Aug 2024
130 points (99.2% liked)

Programming

17666 readers
215 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]



founded 2 years ago
MODERATORS
 

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.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 15 points 3 months ago (3 children)

403 is a category, not a code. Yes I know they're called http codes but REST calls are more complex than they were in 2001. There are hundreds of reasons you might not be authorized.

Is it insufficient permissions? Authentication required? Blocked by security? Too many users concurrently active?

I'd argue the minimum for modern services is:

403 category
Code for front end error displays
Message as default front end code interpretation

As json usually but if you're all using protobuf, go off King.

[–] [email protected] 1 points 3 months ago

Yes, the more information and standards in an api response the better. There should be front end messages and developer messages. URL links to documentation are great too. Standards assist automation and testing.

I understand other viewpoints about maintenance and redundancy, this can cause errors. And the above is too much work for some projects .

But most api start as a temporary or one person project. It’s tempting to be terse and cool with responses . Even more tempting is this is a great cost cutter to not have overly detailed responses.

However

It’s much easier to add in more data to responses now than later. And a future you years later, or strangers who use it , will be grateful. It may be the thing that allows an api to be popular, rather than people use it despite the api

[–] [email protected] -2 points 3 months ago* (last edited 3 months ago) (1 children)

REST calls are same as in 2001. There is no REST 2.0 or REST 2024. Because REST is architecture guideline. It’s just more data sent over it today. HTTP code IS code. Why your system issued it is implementation detail and have nothing to do with resource representation. Examples you provided are not 403. “Too many users active” does not exist in REST because REST is stateless, closest you can get is “too many requests” - 429. Insufficient permissions is 401. I don’t even know what is “blocked by security” but sounds like 401 too. Regardless, you should not provide any details on 401 or 403 to client as it is security concern. No serious app will tell you “password is wrong” or “user does not exist”. Maximum what client should hope for is input validation errors in 400.

For those with “internal tool, I don’t care” argument - you either do not know what security in depth is or you don’t have 403 or 401 scenario in the system in the first place.

Now hear me out, you all can do whatever you want or need with your API. Have state, respond with images instead of error codes, whatever, but calling it REST is wrong by definition

[–] [email protected] 2 points 3 months ago (2 children)

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...

[–] [email protected] 1 points 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

[–] [email protected] 1 points 3 months ago (1 children)

so the creator of gif himself was deliberately transgressive?

[–] [email protected] 1 points 3 months ago

You missed the point:

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

It's analogous.

[–] [email protected] 0 points 3 months ago (1 children)

I've never heard of using protobuf in an HTTP API... But, I guess that should be fine.

[–] [email protected] 1 points 3 months ago

The thing is, it does exists a way to convert grpc protobuf to json one