On Fri, Feb 24, 2012 at 7:31 AM, Rob Brown <[email protected]> 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
=> "here's the user you asked for, but I was not able to look up their LDAP
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
[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/
