Django: Is there a reason to separate api calls into their own url endpoints?

Question

I started a project awhile back and have made a lot of progress since then. In the beginning I didn't think much about restful architecture and how I'd serve data to the frontend. Now, however, it seems the way I am doing so isn't exactly like other projects I see, so here is my question.

What are the main issues with having my views formatted in such a way that when the frontend makes a request, the main view receives it and calls a function based on the action argument, rather than the frontend calling a different url endpoint? Here is an example below...

api.py

def to_return_stuff(request):
    posts = Posts.objects.filter(~Q(user=request.user), is_active=True).order_by('-creation_date').values_list('description', 'pay', 'location', 'creation_date', 'user__username', 'pk', 'coords', 'listing_type', 'image', 'name')
    posts = [p for p in posts if match(p[6], some_coords)]    
    return json.dumps(posts)
    

views.py

def home(request):
    # page initially loads, just serving the static html, then the frontend triggers a fetch request, triggering the populate case, which serves data to the frontend.
    ...
    ...
    if request.method == 'POST':
        match request.POST.get("action"):   
            case "populate":
                payload = to_return_stuff(request)
                return JsonResponse(payload)

            case "create post":
                ...
                return HttpResponse(status=200)

            
            case "remove post":
                ...
                return HttpResponse(status=200)
            
            case "report post":
                ...
                return HttpResponse(status=200)
            
            case "get favorites":
                ...
                return JsonResponse({"some_data": some_data})

    return render(request, 'dashboard.html')

Thank you.

Answer 1

I think you are looking for practical issues so I will de-emphasize some of the more (perhaps) theoretical aspects of REST versus other approaches.

The biggest challenge that I see off is that clients of this service will need to learn how to use these calls and adapt to your custom approach. If you are writing the client-side as well, this might not seem to be an issue but even then you are losing out on the ability to use existing libraries for client support. There are also potential challenges with firewalls etc. It can work, but it's just unusual and if you are making someone else deal with this approach, be prepared for complaints. Another thing you lose out on here is the ability to use standardized documentation tooling. More on that at the end.

The other potential issue you might have with this is if you ever want to split these actions up into separate deployments and/or implementations, you have a much more challenging situation. It's easy to set up a front end load balancer or reverse proxy that directs one URL pattern to server A and another to server B. Can you do the same thing with headers? Maybe, but could narrow your options, be less performant, and/or create extra complexity.

What I would recommend is that you look at a different framework for web services. I have been using FastAPI for while now and it offers a lot of nice features for RESTful services. I am not going to list all the features but the key things for you are that it has an extremely nice syntax for declaring your REST apis and can auto-generate OpenAPI documents host swagger and redoc pages on your host with minimal effort for simple endpoints. For more complex requirements, it works with Pydantic for parsing/writing and validation and those models also get pulled into the openapi.json spec. I think if you try this out, you will see some of what you miss out on by blazing your own trail in this way.