[Catalyst] RESTful response codes.

David Stevenson hoagy at ytfc.com
Fri Feb 24 00:06:55 GMT 2012

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 d=
ocument that determines the status.

You should, IMO, try to steer them to your way of thinking, which seems rat=
her more conventional for a RESTful API.


On 23 Feb 2012, at 23:25, Bill Moseley wrote:

> 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 respons=
e body that includes a { status_block =3D> { status =3D> 'success" } }.    =
I, of course, point out that HTTP already provides a complete list of http =
status codes.  But, they suggest that there might be a time when additional=
 status is needed.   I cannot think of case where that would happen.  PUT a=
 resource and it's either successful or not -- there's no gray area.
> =

> The HTTP spec http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html seems=
 pretty clear.
> =

> Can anyone think of a reason to always return a status?  Or better, any r=
eferences that would be more helpful or convincing than the spec listed abo=
[sig snip]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20120224/7c7c6=

More information about the Catalyst mailing list