When to use HttpResponseBadRequest (http 400) in Django
I recently used HttpResponseBadRequest (http 400) in Django. I was wondering what this means and came across this question . According to the accepted answer, it looks like using HttpResponseBadRequest in a view is always wrong by definition.
I use it for situations where the view is receiving incorrect input or being called in the wrong circumstances, which can only be caused by a badly intending user entering bad data (or from errors in my code).
alternative HttpResponses all look like worst cases in this case. How is HttpResponseBadRequest used by most Django developers? The documentation doesn't seem to explain what the different classes should be used for.
source to share
Apparently the recommended way to handle the impossible / strange user input is not to explicitly return HttpResponseBadRequest, but instead use SuspiciousOperation Exceptions . These in turn lead to HttpResponseBadRequest and some additional logging. So, in the context of the example in my question, 400 status code would be the way to navigate to Django.
source to share
This is not the case for Django. You are actually asking when to use HTTP status code 400 (Bad Request). In general, any page that you successfully present to the user should get a 200 level code. Any request that fails on the server side should get a 500 level code. 400-level codes are for cases where the request failed but was caused by the client and not by a server error. For example, 404 is for the case where the URL matches a path that doesn't exist on the server.
The typical case where the 400 status code is used is for an HTTP request that is sent to a valid supported path where the request parameters (such as GET or POST parameters) are invalid (required parameters are missing or parameters have values that are not of the correct type rather than valid ranges, or do not match the actual enum value in the case of enumeration parameters). This will almost never happen in a custom request (since other parts of your application should only generate well-formed requests) and is significantly more common for APIs you create for other developers (or yourself). That is, if the request fails and you see that it is 400, you can diagnose quite quickly,that the parameters must be changed for correct operation. If this is what you mean by "where the view gets the wrong input" then that seems reasonable to me; however, "under the wrong circumstances" seems like the wrong use of the 400 status code. For the "wrong circumstances" case, it may be more appropriatestatus codes , depending on what you mean by "wrong circumstances".
I must emphasize, however, that there is no exact right answer. When choosing error codes to use, important considerations are: internal consistency between resources within the same site, comprehensibility / expectation by developers using your API (if you create an API), how different status codes are interpreted by the browser, proxies, and search engines.
source to share