[Catalyst] RESTful response codes.

[Bill Moseley]

On Fri, Feb 24, 2012 at 7:31 AM, Rob Brown <rob at intelcompute.com> wrote:

> 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.
>

I was going to disagree with you, but I think we are talking about two
differnt things.

For a 400 response I completely agree with you.  In that case I do return a
very detailed and standard-formatted response that explains why the client
request could not be processed.


This consumer of he API is arguing that the 2xx HTTP response are not
enough of a "status" -- that *every* request needs a status (and that
should not mix HTTP "transport" codes with business logic).  But, I cannot
think of an example where this would be the case.

So you do GET /user/1234 and it returns a 200 with a status saying { status
=3D> "here's the user you asked for, but I was not able to look up their LD=
AP
id because the server was down.  Hope you don't mind the omission." }.
 That's a scary road to head down, no?

I cannot think of a POST, GET, PUT, or DELETE on a resource where the
status cannot be represented with HTTP response status -- because that's
how it is designed.



-- =

Bill Moseley
moseley at hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20120224/0a1b5=
087/attachment.htm