Programming

20985 readers

59 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

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 !webdev@programming.dev

founded 2 years ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

MaungaHikoi@lemmy.nz

UlrikHD@programming.dev

RFC 9457: Problem Details for HTTP APIs (www.rfc-editor.org)

submitted 2 years ago by lysdexic@programming.dev to c/programming@programming.dev

9 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] atheken@programming.dev 3 points 2 years ago* (last edited 2 years ago) (8 children)

I quickly skimmed this, and it looks kinda overwrought to me.

This is the format I’ve been using:

{
success: bool
error_code: number,
message: “human-centric error message”,
context:  { optional, user-defined details }
}

[–] lysdexic@programming.dev 2 points 2 years ago* (last edited 2 years ago) (7 children)

Your format looks half baked and not thought all he way through. Take for instance the success bool. What info does this add that error_code and the request's own status code doesn't already send? And what's the point of context if it is both unspecified and optional?

[–] TehPers@beehaw.org 1 points 2 years ago* (last edited 2 years ago) (2 children)

If both success and error responses include the success field, then that can be a common discriminator between bodies of successful responses and bodies of error responses. Where this adds value beyond the request's status code, I'm not sure. Maybe it's useful in aggregated responses where partial successes are allowed (like POSTing a batch of objects)?

Your format looks half baked and not thought all he way the way through.

This does seem a bit heavily worded. There's likely a reason they originally chose and continue to use that format, and it could be as simple as "all our other APIs use this format" or similar. There's more to choosing a response schema than what is theoretically the most efficient way of communicating the information.

[–] atheken@programming.dev 2 points 2 years ago* (last edited 2 years ago) (1 children)

Thanks, and you are basically correct on both counts:

I supported an API that had a Batch endpoint that could be "partial success" -- and that was a mess.
I have been experimenting with something where you have standardized elements because the Fetch API doesn't throw on 4XX/5XX, so having one if check, rather than two, makes sense.

At this point, it's an experiment.

[–] TehPers@beehaw.org 1 points 2 years ago* (last edited 2 years ago)

Status codes for batch operations is always a mess. Do you return a 400 because one request made no sense even if the rest succeeded, or return a 200? 207 exists but it's not really directly part of the HTTP spec and only seems to support XML response bodies.

Edit: @lysdexic@programming.dev if the RFC proposed a solution to responses for batch operations where some responses may contain errors, then that would be interesting. The RFC, from what I understand, proposes a format for error responses, but does not seem to support mixed error/success responses.

load more comments (4 replies)