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: Mark Nottingham <mnot@mnot.net>
Date: Fri, 25 Jan 2013 08:29:02 +1100
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>
Message-Id: <C0775E7D-05FC-4C9F-B765-4814C1D145A2@mnot.net>
To: Nico Williams <nico@cryptonector.com>
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.


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

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