3 ms·
I don't... entirely mind this, this is how most APIs respond errors anyway in my experience, especially if they expect them to both be used for fully fledged br
by noirscape 4y ago
I don't... entirely mind this, this is how most APIs respond errors anyway in my experience, especially if they expect them to both be used for fully fledged browser clients that display errors and for API-only clients.
The only thing I don't like here is the "type" parameter and how its expected to be an URI. That will only hamper implementation, considering most API documentation isn't distributed as individual error pages. Most of the time you either have a PDF document (for private APIs), a single big HTML page (which to be fair, can be anchored) or in some cases, physical documentation.
Personally I'd just have allowed type to be a simple string that informs the machine about the type of exception that occurred, and expect people implementing the API to figure out what that means (ie. Through external documentation) instead of making it a URI.
The out of credit example would have a "type" of "OutOfCreditException" in my suggestion, of course adjustable by whatever is preferred.
This RFC is just a slightly pointless standardization that has one weird thing in it that nobody actually does, which to be fair "here's what were all doing but slightly different, so get to work" can describe a lot of RFCs.
- valevino 4y agoI agree with you. But it's nice to have some reference about how we can return a response error. I already see too much creativity, weird formats and useless informations in many APIs, so this can work as a basic quality threshold.
- mstade 4y agoWell, the spec says that the type is a URI, only encouraging implementers to use URIs that can be dereferenced to human readable documentation but not forcing it. You’re free to use whatever URI suits your purpose, like a URN or maybe even your on scheme. All the spec asks is that it’s a URI which is a wide and flexible range of identifiers, only a subset of which actually point somewhere.
- wongarsu 4y agoI fully expect people to adopt something like "error:validation-error" for the type field, followed by decades of arguments whether that's ok (it follows the URI format, but does it identify a resource?)
- chrismorgan 4y agoThe sort of people that deliberately use the Problem Details format rather than rolling their own are the sort of people who will agonise over the URIs they choose, making sure they’re meaningful in some way. (I’m simplifying, of course, but I think it’ll be a decent generalisation.)
- mstade 4y agoI mean, isn't that how it should be though? Pick a scheme (preferrably not in the IANA registry), design something, figure out what works in practice, optionally find it so nice that you'd like to share it with the world and make an RFC to register a new scheme. Rinse and repeat.
- cxr 4y agoNot in this case, no; not when it's trivial to put a URL there.
- spion 4y agoIts not pointless. Proxies (such as istio), caches or middlewares (like auth and validation) should be able to set errors without interfearing with the main application errors. The namespacing scheme allows that.