So that I don't have to stuff a JSON or an XML parser on the client.
Section 3.1 https://www.rfc-editor.org/rfc/rfc7807#section-3.1 suggests there's nothing in there that couldn't be done with response headers. A couple of URIs, some strings, and a useless status field. Useless because in reality a client will always have to obey the response status code.
Extensions can be easily done via headers. x-amz-... have paved the path.
A header-only solution would still need a parser, because it formally includes arbitrary nested structures. There’s certainly prior art for that in headers, and you may even have a capable parser already at hand. But for better or worse that’s probably a much less likely scenario than having a JSON or XML parser.
Even so, the RFC specifically addresses arbitrary formats, and there’s nothing in it which would preclude headers as one such format.
> because it formally includes arbitrary nested structures
In case of XML, yes, in case of JSON... where? Extensions?
> Even so, the RFC specifically addresses arbitrary formats, and there’s nothing in it which would preclude headers as one such format.
Yeah, the Appendix B is mightily confusing. It basically says "in case of specific requirements, do as you please":
This specification does not make specific recommendations regarding
embedding problem details in other formats; the appropriate way to
embed them depends both upon the format in use and application of
that format.
So basically it does not address anything. I begin to wonder what’s the point of this RFC.
Was it the case “oh, we use this inside of Akamai but some of our clients require some form of a standard so can we please push this one through”?
I mean, surely if you’re going to propose a standard that suppose to address some shortcomings of HTTP, you’d do it so that it can be used by anybody without any dependency other than HTTP itself. No?
> So basically it does not address anything. I begin to wonder what’s the point of this RFC.
If it doesn’t solve a problem you have, it’s okay to recognize that without categorically declaring it doesn’t solve any problems. The point of the RFC is very clearly stated, and its scope is intentionally limited and flexible.
The problem it identifies is a common set of error conditions, and some general ways that those general conditions might carry more detail. The solution proposed is a general way of modeling those, with some proscribed semantics for popular data formats and a less proscribed and very permissive way to incorporate the same approach in any format whatsoever.
> I mean, surely if you’re going to propose a standard that suppose to address some shortcomings of HTTP, you’d do it so that it can be used by anybody without any dependency other than HTTP itself. No?
They did do that. If you’re so insistent that it use headers only and no semantics specified outside of HTTP, you must already know that the Link header has all of the structural semantics you’d need to implement the same data structures. You’d still need to parse the header, but again if you’re so invested in that particular approach you probably already have a solution to that.
If your expectation is that this RFC uses only HTTP headers but comes with built in semantics for arbitrary structured data within HTTP headers, your demand is impossible to satisfy. HTTP headers are inherently a dictionary relation of strings to strings, until HTTP itself is modified to accommodate something more sophisticated. And if anyone tried to make that change it would face far more backlash than “feel free to pack whatever data into that dictionary you want, if that’s your thang”.
Section 3.1 https://www.rfc-editor.org/rfc/rfc7807#section-3.1 suggests there's nothing in there that couldn't be done with response headers. A couple of URIs, some strings, and a useless status field. Useless because in reality a client will always have to obey the response status code.
Extensions can be easily done via headers. x-amz-... have paved the path.