this post was submitted on 01 Aug 2023
38 points (97.5% liked)
Programming
20830 readers
228 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 !webdev@programming.dev
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Your format looks half baked and not thought all he way through. Take for instance the
successbool. What info does this add thaterror_codeand the request's own status code doesn't already send? And what's the point ofcontextif it is both unspecified and optional?Context is whatever makes sense to provide to a consumer to help them debug it or respond to it - the same basic idea as in the rfc under
details. IMO, it can't easily be generalized. Some APIs may have context to provide, others may not. These could be validation errors in a structured format, or backoff timings in the case of a 429.Success is something that you can sniff for after deserializing, as IIRC Fetch API will not throw except for a network errors, even in the event of a 4XX or 5XX.
Consider something like:
if(!obj.error_code){}vsif(obj.success){ }. Certainly, you could consolidate theerror_codeandsuccessmember, but with the sloppy truthiness of testing in Javascript, including something like that as a standard part of all responses may make sense.No> Context is whatever makes sense to provide to a consumer to help them debug it or respond to it
So it's both optional and unspecified. This means it can't be parsed or relied upon, specially by consumers. It's useless.
No, it isn't. Contrary to your ad-hoc format, RFC9457 specifies exactly the data type of
detailand what's its purpose. This allows third parties to reliably consume resources that comply with RFC9457 while your ad-hoc format leaves clients no option other than to ignore it.It matters nothing what services can produce. What matters is whether clients can consume it. Your ad-hoc format fails to specify this field, which is optional, and thus leaves no option other than to ignore it. It's unusable.
What the Fetch API does or does not do is irrelevant. The responsibility of putting together a response and generating the resource shipped with it lies exclusicely in your service. If it outputs a resource that is unable to tell clients what went on, that's a problem cause by both how your service is designed and the ad-hoc format it outputs.
The main take is that RFC9457 is well specified and covers basic usecases, while your ad-hoc format is broken by design. Thus when you describe the RFC as "overwrought", you're actually expressing the half-baked approach you took.