On Fri, Sep 9, 2011 at 7:11 PM, Ron Wilson <[email protected]> wrote:
> Also, I agree that HTTP status codes should be for transport rather
> than application errors.
>
:-D. Okay, so there's 2 votes for that.
In my experience (and i've written boatloads of JS- and Java-based Ajax the
past 2 years), i find it more intuitive to write code where i have a clear
separation of transport-vs-app errors.
e.g. if we use jQuery for the Ajax then an HTTP XYZ (any error code) will
trigger the error() AJAX callback, and from there we have no recovery
strategy (and can't say much about what happened to the user). If, OTOH, the
app returns:
{ resultCode:123, resultText:"broken code"}
then success() AJAX callback is called and the client can interrogate
resultCode. In some cases he might be able to retry, whereas others he has
no choice but to fail (e.g. don't retry a failed login, but maybe retry a
failed wiki page fetch 2 or 3 times). Even if he can't retry, assuming the
resultCode is a well-defined value then he can tell the user what the
problem was (which he can't do all that accurately with HTTP codes).
The REST model breaks that pretty badly, IMO.
That said, i recognize the benefit of "vague error codes", but during the
development/debugging i want the codes to be as specific as possible so that
i can track down errors. It also helps when supporting users. But for
production servers i agree that the error codes should be "vaguified" a bit.
The current model supports that but there is no code yet to dumb the codes
down (and the list of codes will still be in flux for a while).
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
