[Proposal] Custom JsonResponse Status Classes

Django Internals
1

We created custom JsonResponse status subclasses for a project and have been using them regularly ever since. So I thought I would see if there would an interest for something like this among the Django developer community. We have been using the JsonResponse class frequently lately, and the subclasses have really helped us with keeping our code readable and the JSON responses more consistent.

I have it set up similar to the HttpResponse subclasses, only the custom classes take a specific message and any additional arguments we want to add in.

class JsonResponseStatusBase(JsonResponse):
    def __init__(self, message: str, status_code: int, **kwargs):
        http_status = HTTPStatus(status_code)
        response_data = {
            'status': http_status.value,
            'title': http_status.phrase,
            'message': message,
        }
        response_data.update(kwargs)
        super().__init__(data=response_data, status=status_code)

class JsonResponseBadRequest(JsonResponseStatusBase):
    def __init__(self, message: str, **kwargs):
        super().__init__(message, status_code=400, **kwargs)


class JsonResponseNotFound(JsonResponseStatusBase):
    def __init__(self, message: str, **kwargs):
        super().__init__(message, status_code=404, **kwargs)

# etc

I didn’t see any proposals on here or in the Google group. Do you think there is a need for these? If so, I’ll create a ticket with Django. Suggestions are welcome!

2

Hi @leenapthine — thanks for the post.

Just personally, I wouldn’t add these subclasses myself… They’re very lightweight, and easy to add in user projects if so desired.

I know we have the Http versions already, but I’ve often thought that they’re unnecessary: it takes longer to pull up the docs to find the right subclass then it does to pass the status code to the response constructor. On the flip side — going the other way — it takes longer to map class names back to the status code than it would do to just read it.

Maybe some folks find the class names more memorable IDK. I know for me the status codes themselves (or the HTTPStatus constants) are more useful to see and use.

(Just one view.)

1 Like
3

Yup me too, adding specific response classes tied to a response code + mime type seems like over-engineering to me :slight_smile:

4

Same opinion here - no need to build subclasses.

A while ago I proposed filling in some of the “missing” HttpResponse subclasses. The end result was instead to document using HTTPStatus in this section: Request and response objects | Django documentation | Django

1 Like
5

Member of the same team here. We found that the proposed subclasses are easier to read and use consistently, and felt that the pattern is in line with the existing (and maybe overengineered, sure) HttpResponse subclasses. If we were submitting a PR for this, I would probably align to the existing HttpResponse subclasses for the most common use cases: if somebody needs 418, for example, they can go the custom route.

At any rate, the community has spoken! We’ll probably fold the code into a local Django helper library and if anybody comes along and is interested in this, feel free to reach out.

Thanks for the feedback.

6

That’d make a good blog post! “Here are the N JsonResponse subclasses we needed in our project”, and some source. Others could copy and adapt as needed.

7

Would folks opinions change if we had a standard API integration in Django?