On Fri, 24 Feb 2012, Bill Moseley wrote:
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.
I think part of this comes down to your choice of URI and what represents
a "thing" in your web app.
If you're able to separate each thing into a sane URI and support PGPD as
appropriate on every URI, then the HTTP statuses should "just work", for
some value of "just".
One thing that can be a bit though is some sort of batch update, where you
want to update more than one thing at once for efficiency. What do you do
if part of the batch succeeds and part fails? Maybe you just run
everything in a transaction so this isn't possible.
-dave
/*============================================================
http://VegGuide.org http://blog.urth.org
Your guide to all that's veg House Absolute(ly Pointless)
============================================================*/
_______________________________________________
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/
