- From: Nico Williams <nico@cryptonector.com>
- Date: Thu, 24 Jan 2013 15:22:24 -0600
- To: Phillip Hallam-Baker <hallam@gmail.com>
- Cc: Julian Reschke <julian.reschke@gmx.de>, Grahame Grieve <grahame@healthintersections.com.au>, Tim Bray <tbray@textuality.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On Thu, Jan 24, 2013 at 2:34 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote: > On Thu, Jan 24, 2013 at 12:48 PM, Nico Williams <nico@cryptonector.com> > wrote: >> I've seen APIs that handle errors in JSON-encoded response bodies, >> including one that always returns success in HTTP but errors in the >> response body, which is kinda weird, but if none of the HTTP status >> codes make sense... (that was the author's defense). > > It makes perfect sense from a layering perspective. > > In an RPC call I probably want HTTP errors to be strictly limited to > reporting network failures. 'entry not found' is a completely different > result from 'machine is down' > > entry not found is arguably a successful transaction that returned an empty > list of results. That was the author's defense. I understand Julian's objection too, but it made no difference.
Received on Thursday, 24 January 2013 21:22:56 UTC