Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error format #7

Open
erincandescent opened this issue Jul 16, 2024 · 0 comments
Open

Error format #7

erincandescent opened this issue Jul 16, 2024 · 0 comments

Comments

@erincandescent
Copy link

So I very much love how Nexus is a very simple solution to a ubiquitous problem in API design; but one objection I have is the Failure type. One of the last things the world needs is Yet Another JSON+HTTP Error Format

RFC 9457 (that replaces 7807) defines a common JSON error format for HTTP APIs that is growing in popularity. It's very simple and minimalist, and (IMO) does precisely what a common machine-readable error format must.

I feel that using this instead of the Failure type would align with growing practice for HTTP (and particularly JSON-based) APIs.

I don't think this would be a big change to the spec:

  • The definition of Failure could be dropped,
  • Instead of "Content-Type: application/json; Body: A serialized failure" the spec would say "Content-Type: application/problem+json; Body: A serialized RFC 9457 Problem report".
  • Perhaps instead of the "Nexus-Operation-State` response header a specific problem type could be defined for an operation being canceled. (I think you still need it for callbacks, but there perhaps the only options are success or failure; cancelation is really just one specific failure cause anyway)

I realise this might be the kind of change thats annoying to make at this point, but I think the alternative is that people will be cursing having yet another error format to deal with for years to come.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant