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 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?
>
> Thanks,
>
> --
> Bill Moseley
> [email protected]
> _______________________________________________
> List: [email protected]
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/[email protected]/
> Dev site: http://dev.catalyst.perl.org/
Francisco Obispo
email: [email protected]
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
