Here's a discussion I'm having with a consumer of an API.
For a RESTful service they would like the API to ALWAYS include a response
body that includes a { status_block = { status = 'success } }.I, of
course, point out that HTTP already provides a complete list of http status
codes. But,
I think your API needs to provide a mapping between HTTP response codes and
your intended response codes.. that should be enough to keep them happy..
201- created
401- access denied
…
etc.
On Feb 23, 2012, at 3:25 PM, Bill Moseley wrote:
Here's a discussion I'm having with a consumer of an
I suspect he's used to XML-RPC, where it's conventional to return, on error, a
valid XML document and an HTTP status of 200. It's the content of the document
that determines the status.
You should, IMO, try to steer them to your way of thinking, which seems rather
more conventional for a
@lists.scsys.co.uk
To: The elegant MVC web framework catalyst@lists.scsys.co.uk
Subject: Re: [Catalyst] RESTful response codes.
Date: Fri, 24 Feb 2012 00:06:55 +
I suspect he's used to XML-RPC, where it's conventional to return, on
error, a valid XML document and an HTTP status of 200. It's the content
On Fri, 24 Feb 2012, Bill Moseley wrote:
This consumer of he API is arguing that the 2xx HTTP response are not
enough of a status -- that every request needs a status (and that
should not mix HTTP transport codes with business logic). But, I
cannot think of an example where this would be the
On Fri, Feb 24, 2012 at 10:08 AM, Dave Rolsky auta...@urth.org wrote:
One thing that can be a bit though is some sort of batch update, where you
want to update more than one thing at once for efficiency. What do you do
if part of the batch succeeds and part fails? Maybe you just run
