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
mose...@hank.org
_______________________________________________
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/
