[sorry for the late response; this got lost in drafts, but it's enough of a
sore point for me to want to post it]
On Sun, Jul 15, 2012 at 12:30 PM, Jani Tiainen
<rede...@gmail.com<javascript:_e({}, 'cvml', 'rede...@gmail.com');>
> wrote:
> I think "letting to explode" is all about coloring the bike shed. It all
> depends on a API contract - if parameter is required (thus meaning missing
> it is a critical error) it should explode.
>
> In case of incorrect request I prefer to raise 400 (Bad Request) with some
> explanation what went wrong. Since 500 is usually meant for "catch all"
> unexpected errors that happened in web server and server can't be more
> precise what happened. I've done that according to RFC 2616 (HTTP 1.1
> Specification) where is said that 4xx codes are meant for "client side
> error" (Section 10.4), and 5xx which means "server error" (Section 10.5)
>
> But I think all of that is matter of taste...
>
>
I wouldn't call it a matter of taste; this is the spec for communicating
over HTTP.
Certainly, if you have full and complete control over the server, and over
every client, then by all means use 500 errors to mean whatever you want.
You could also signal an error with a 200 OK message, or just make up your
own status codes.
Status codes have meaning though, which is important as soon as you want to
open up your interface to any other clients. A 400-series code means that
the client request had a problem, and the specific code tells the client
whether there is anything that can be done about it.
A 500 error, on the other hand, means that there is an error (read: bug) in
the web server code. Something happened (almost certainly in response to a
client request) that the server was not properly coded to handle, and the
result was an unexpected exception.
The distinction is important: it communicates who has the responsibility
(or at least the capability) to fix the error.
As developers, we should be reporting 400-series errors every time we can
detect an issue with a request, as a courtesy to clients. We should never
deliberately be creating 500 errors. The only responsible thing to do when
a 500 is seen in the logs is to track down the source of it and fix the bug.
--
Regards,
Ian Clelland
<clell...@gmail.com <javascript:_e({}, 'cvml', 'clell...@gmail.com');>>
--
Regards,
Ian Clelland
<clell...@gmail.com>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
