- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 25 Jan 2013 08:29:02 +1100
- To: Nico Williams <nico@cryptonector.com>
- Cc: Phillip Hallam-Baker <hallam@gmail.com>, "Julian F. Reschke" <julian.reschke@gmx.de>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
This sub-thread is getting mildly off-topic; if we start going down the rabbit hole of "what is an HTTP API?" (as dear as that subject is to my heart), I fear we'll never surface again. Cheers, On 25/01/2013, at 8:22 AM, Nico Williams <nico@cryptonector.com> wrote: > 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. > -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 24 January 2013 21:29:36 UTC