[HN Gopher] Problem Details for HTTP APIs
___________________________________________________________________
Problem Details for HTTP APIs
Author : stefankuehnel
Score : 15 points
Date : 2023-03-29 21:47 UTC (1 hours ago)
(HTM) web link (www.rfc-editor.org)
(TXT) w3m dump (www.rfc-editor.org)
| mholt wrote:
| ACME (RFC 8555) uses this, so I've implemented the client-side of
| it. It's alright. I do think it's nice to have some sort of semi-
| standard structure for error details. The namespace URN stuff
| feels like ceremony though and sometimes I wonder if the spec is
| a little over-engineered, but overall I'm glad there's something
| we can default to for public APIs.
| stanleydrew wrote:
| Seems like this proposal would be more appropriate as part of a
| JSON-specific protocol with HTTP as transport.
| mholt wrote:
| But what about the XML half?
| riffic wrote:
| would be nice to add (2016) or the actual RFC number (7807) in
| the subject.
| hcarvalhoalves wrote:
| Not really a HTTP thing if it's based on JSON response body,
| right?
| mholt wrote:
| It's for HTTP APIs, and it's XML too.
| rad_gruchalski wrote:
| The idea seems okay, a standard method to report errors would be
| quite nice to have. But why JSON and XML only? Why no header-
| based option?
| mholt wrote:
| Aside from technical limitations of HTTP headers, why do you
| need a header-based solution?
| Arnavion wrote:
| That's why they said:
|
| >>But why JSON and XML only?
|
| A header-only solution would be independent of the response
| payload format.
| rad_gruchalski wrote:
| So that I don't have to stuff a JSON or an XML parser on the
| client.
___________________________________________________________________
(page generated 2023-03-29 23:00 UTC)