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

[Mark Nottingham <[e-mail]>]

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 <[e-mail]> wrote:

> On Thu, Jan 24, 2013 at 2:34 PM, Phillip Hallam-Baker <[e-mail]> wrote:
>> On Thu, Jan 24, 2013 at 12:48 PM, Nico Williams <[e-mail]>
>> 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/