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...


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)


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.

  • Reinventing the wheel can work... it's just a lot of extra work. For example: you might want to secure different endpoints according to different roles. If you use one view per endpoint it is easy to integrate with existing frameworks using some decorator, here you'd have to manually check everything which is cumbersome and also you have a high risk for errors. You also cannot adjust parameters like timeouts/caching per endpoint easily, since for the webserver there is only one endpoint.
    – GACy20
    Oct 7, 2022 at 14:51
  • Finally this is just spaghetti code. You have to actually read the whole code to understand what the API calls are. If you instead have separate views with clearly readable names just looking at the function signatures & names you can understand a lot of how the API works. You can also use docstring to automatically generate formatted documentation for your API...
    – GACy20
    Oct 7, 2022 at 14:52
  • Thanks @GACy20, appreciate the insight.
    – noob112233
    Oct 7, 2022 at 16:07

1 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.

  • Thanks, I'll look into these links. Appreciate the answer.
    – noob112233
    Oct 7, 2022 at 16:10
  • @noob112233 No problem. In the future, you might want to wait a bit before accepting an answer here as it can discourage other answers.
    – JimmyJames
    Oct 7, 2022 at 16:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.