[Catalyst] RESTful response codes.

Rob Brown rob at intelcompute.com
Fri Feb 24 00:31:58 GMT 2012

Think I've been here before...

Sounds like this is down to the separation of transport vs application.

If the request was successfully received, you should return a 200.

If your app decides something was wrong, then it's for your own message
framework to send that information back.

Don't just jump on the back of HTTP codes and leave the client wondering
if it just a bad line, etc.


Web Design and Online Marketing


-----Original Message-----
From: David Stevenson <hoagy at ytfc.com>
Reply-to: The elegant MVC web framework <catalyst at lists.scsys.co.uk>
To: The elegant MVC web framework <catalyst at lists.scsys.co.uk>
Subject: Re: [Catalyst] RESTful response codes.
Date: Fri, 24 Feb 2012 00:06:55 +0000

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.


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 at 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/

More information about the Catalyst mailing list