3 ms·
We use this in our generic REST client[1] to emit nicer error messages to the user of the client. As much as possible our client uses best practices and open st
by treve 4y ago
We use this in our generic REST client[1] to emit nicer error messages to the user of the client. As much as possible our client uses best practices and open standards where applicable. If you don't use application/problem+json you just get a HTTP errors, but with application/problem+json we'll extract the human-readable error message and such.
[1]: https://github.com/badgateway/ketting https://github.com/badgateway/ketting
- dwaite 4y agoI implemented the older RFC in Java, doing a few fun things: 1. API were ultimately expected to throw a ProblemDetailsException. A response filter would catch and wrap other unexpected throwables into a problem details exception. 2. The resulting exception handler preferred [a/p+j, a/j, a/p+x, a/x, t/h] media type ordering (with abbreviated names), which meant that a browser would get HTML errors while something like curl would get application/problem+json I considered a XSLT on the XML output, but that just seemed like going for bonus points.