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 RESTful API.
Regards
David
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 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, 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
> references that would be more helpful or convincing than the spec listed
> above?
[sig snip]
_______________________________________________
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
