api_view['POST', 'GET'] against SOLID principles?

Question

It's not a problem I'm facing its just an open discussion. in Django Rest framework we declare a decorator @api_view[] and it take an argument like

1. POST
2. GET
3. PUT
4. DELETE

in my case I'm allowed to put more than one argument in the decorator and make one function made more than one responsibility like

  @api_view['POST', 'GET]
  def fbv_list(request):`
       if request.method == 'POST':
           #do something
       if request.method == 'GET':
           #do something

in this case fbv_list make more than one thing which is POST and GET isn't in this case this function is against the Single responsibility class which is from SOLID principles ????

That's my question and if yes what is supposed to do to avoid breaking the SOLID .

Thanks in advance.

Answer 1

I will start my answer by quoting the definition of a view from Django's official docs:

A view function, or view for short, is a Python function that takes a web request and returns a web response. This response can be the HTML contents of a web page, or a redirect, or a 404 error, or an XML document, or an image . . . or anything, really. The view itself contains whatever arbitrary logic is necessary to return that response.

The responsibility of the view is to take a web request as input and return a web response as the output. DRF APIs are also "views", so this definition fits there as well.

Breaking it down further, the core responsibility of the view is to take a request and perform "arbitrary" logic on it. What's arbitrary? When a view receives a request, how will it decide what set of operations are to be performed? Is the request attempting to get some information from the system, create a record, or maybe try a complex update operation on the data models? That's what the view will have to decide because that is its primary purpose. Based on the nature of the input request, the type of output will change. However, the core functionality is still the same. It does not violate SRP. I am also listing one of the code snippets from Django docs that is using the same pattern:

from django.http import HttpResponseRedirect
from django.shortcuts import render

from .forms import NameForm

def get_name(request):
    # if this is a POST request we need to process the form data
    if request.method == 'POST':
        # create a form instance and populate it with data from the request:
        form = NameForm(request.POST)
        # check whether it's valid:
        if form.is_valid():
            # process the data in form.cleaned_data as required
            # ...
            # redirect to a new URL:
            return HttpResponseRedirect('/thanks/')

    # if a GET (or any other method) we'll create a blank form
    else:
        form = NameForm()

    return render(request, 'name.html', {'form': form})

P.S. Do check this link out to see how SRP can be misleading and how its purpose and usage are subjective.