You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
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.
The text was updated successfully, but these errors were encountered: