W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: Should Web Services be served by a different HTTP n+1?

From: Nico Williams <nico@cryptonector.com>
Date: Thu, 24 Jan 2013 15:22:24 -0600
Message-ID: <CAK3OfOjWAJeBYCEftNES6o==7bUUUEpHZEkfJKNJRPOvvG62KA@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:09 UTC