Feature Request: Add hooks for CUD responses in related mixins.

[nafeesanwar]

There is often a scenario when you have to send a custom response after create, update, or delete operation. There is no mechanism, when using generic views, to intercept the outgoing response and replace or modify it. You just have to override the whole action method.

Example

If someone is using CreateAPIView and a SignupSerializer for user signup, he might want to send back just a message instead of some resource representation. He has to override the create method for this purpose.

    def create(self, request, *args, **kwargs):
        serializer = self.get_serializer(data=request.data)
        serializer.is_valid(raise_exception=True)
        self.perform_create(serializer)
        headers = self.get_success_headers(serializer.data)
        return Response({ 'message': 'SOME_MESSAGE' }, status=status.HTTP_201_CREATED, headers=headers)

Proposal

Add new hooks in the API mixins to get the final response from view for the create, update, delete (and maybe list and retrieve also) operations. Something like this.

class CreateModelMixin:
    """
    Create a model instance.
    """

    def create(self, request, *args, **kwargs):
        serializer = self.get_serializer(data=request.data)
        serializer.is_valid(raise_exception=True)
        self.perform_create(serializer)
        headers = self.get_success_headers(serializer.data)
        response = self.get_create_response(serializer)
        return Response(response, status=status.HTTP_201_CREATED, headers=headers)
    
    def get_create_response(self, serializer):
        return serializer.data

which will simplify the above example to

def get_create_response(self, serializer):
    return {'message': 'SOME_MESSAGE'}

I think we can make the changes in a non-breaking manner. If this proposal is acceptable, I can contribute the code, tests, and documentation.

[carltongibson]

Hi.

The standard reply here is that the mixins are so simple that you should just implement what you need.

This in contrast to making them overly complex adding hooks for every possible customisation.

It's not worth the API complexity, just write it inline. Cleaner. Easier to comprehend. Easier to maintain.

Hope that makes sense.

[tomchristie]

Seconding @carltongibson - this falls into what I consider to be a complexity-feedback-loop.

We'd be exchanging "customize the response message with 6 lines of code" for "customise the response message with 2 lines of code", but at a cost of adding an extra method. (Which adds a tiny bit of extra indirection and have-to-think-about-it code flow, and makes adds marginally more complexity for folks overriding the create method.)