Generics CBV for creating simple JSON APIs

Using Django Forms & APIs
1

This might have been discussed in the past, apologies if it’s the case, I couldn’t find the discussion in the forum.

I have many projects that are not full blown SPA and don’t really require all the bells and whistles of DRF. However, it’s quite complex to write even the most simple APIs without another framework on top of Django. I think it would be awesome if Django offered an easy way to do simple APIs out of the box.

The way I see it, it could be a stripped down versions of generic CBVs that output JSON like this :

class JsonListView(View):
    model = None
    fields = None
    paginate_by = 25
    page_kwarg = "page"

    def get_queryset(self):
        return self.model.objects.all()
    
    def get_paginated_queryset(self, queryset,):
        page = self.request.GET.get(self.page_kwarg) or 0
        start = int(page) * self.paginate_by
        end = start + self.paginate_by
        return queryset[start:end]
    
    def get(self, request):
        queryset = self.get_queryset().values(*self.fields)
        queryset = self.get_paginated_queryset(queryset)
        return JsonResponse(list(queryset), safe=False)
    
class UserListView(JsonListView):
    fields = ["id", "title", "body"]
    model = User

The benefits:

  • Very easy to learn if you already use CBV
  • Quick to draft simple APIs without having to add and learn new libraries
  • Makes vanilla Django easier to integrate with popular javascript frontends

If the idea sounds nice, I would like to volunteer to make a formal proposal with the complete API for the views.

2

This is one of those categories that could be best served initially as a third-party package to see how well it works, and to allow for more rapid development and improvement than if it were committed to core right away.

I would suggest you create these as an independent package to see what the reaction is - help identify what the issues may be with what you’re creating, and what people are actually finding usable or helpful.

Note: Your second and third points:

do not (generally) carry any weight within the Django community. One of Django’s strengths is its ability to use and integrate third-party packages. Those packages form a key part of Django’s ecosystem and should be considered a benefit rather than an issue that needs to be resolved.

Not everything needs to be in Django core.

3

I appreciate the simplicity of the statement, but it might be considered somewhat oversimplified. Were Django to adhere strictly to this philosophy, it could potentially stop any innovation. I love the new features that enrich Django each year. I eagerly anticipate new additions, yet I also recognize the constraints imposed by a community operating with finite resources and time.

Designing APIs extends beyond a passing trend. It raises questions about why Django core concentrates on forms and templates but defers JSON rendering to third parties. While external libraries like DRF serve their purpose admirably, relying on a third party differs significantly from having the functionality in the core. For example, DRF has not released an update in the past 15 months and lacks support for the latest major Django release.

4

See other discussions here in the forum - or on the developer’s mailing list - about why there’s a lot of “friction” (my term) regarding adding features to core. (It’s a perspective and an approach that I’ve come to appreciate.) Briefly, it’s not only about the ability to support and maintain, but also about a strong desire to get it right.

There are many things that might be in core - and so it’s appropriate to try them out before they become a core component. And that’s why the general recommendation is to implement an idea as a third-party pacakge first. (This is not always possible - there will be functions that can only effectively be provided as a change to core.)

Note: “Not everything needs to be in core” means exactly that. It doesn’t mean that there aren’t things that should be in core - or that the things in core shouldn’t be enhanced or improved. But core shouldn’t be the proving ground for every good idea that gets proposed.

I was actually a fly on the wall during a hallway track discussion about a JSON/REST API in core at DjangoCon - apparently one of the issues is that there are multiple designs that have been developed to support such a framework within Django, and so the question becomes which design to support. The DRF is not the only way to do it, and so there’s a question about which approach to take. (The rest of the discussion went over my head - I’m not in a position to provide any details about it, and it’s quite possible that I haven’t even related this much of it correctly.)

Side note: I don’t use DRF, so I don’t follow what’s going on with it. Thank you for making me aware of its status.

However, my conclusion drawn from this is likely different from yours. To me, this is a clear indication that DRF itself should not be in core.

Keep in mind that there’s no paid development staff for Django.

That means that if there’s some work needing to be done to DRF to make it fully compatible with Django 5.0, some volunteer would need to do it. And if a volunteer has the time to work on it with it being in core, then they have the time to work on it as a third-party product.

Or, if there’s no one with the time/knowledge/energy to work on it in core, then you are potentially slowing down the release of other core features that can’t be released because those features break the functionality provided by DRF - and that is the maintenance cost involved with continuing to add features to core.

1 Like
5

I appreciate the explanations. I’m new to the community and I had some guesses this “friction” existed but couldn’t follow the historical trace to any decisions concerning API views using the public archives.

Not quite. Moving DRF forwards and 4-5 JsonViews in core (which really is why my proposal is) doesn’t represent the same amount work for a contributor.

6

Great! Demonstrate it as a third-party package then. Show exactly what it is that you’re looking to provide. Allow the community to evaluate its usefulness and desirability, and possibly identify shortcomings with the approach you have chosen. Let people compare it with the other approaches to see what might be core-worthy.

1 Like
7

@betaflag I think @KenWhitesell is right here.

The “bring DRF into core” request comes up often enough, but it’s not clear what the right answer there is.

It’s not just the views — CBVs themselves being only popular with about half the community it seems… — it’s JSON handling in the request, and serialisation, to name just the big two.

Taking serialisation, if it had happened 10 years ago then DRF’s approach would likely have been the way to go, but all the interest now is in Django-Ninja’s Pydantic based approach, and whether something similar using more modern approaches is available. How that will play out, we just can’t say, so much better it be done outside of core.

There is ongoing work to allow pluggable content parsing in the request object, so maybe we get that bit done soon(ish) :crossed_fingers:

Views would be the last layer I would add. They’re dependent on all the rest.
And easy enough to add in your own project.

As per DRF, it’s highly unlikely there’s any incompatibility with the new versions of Django — it’s been essentially stable for more than a decade. If you want to make sure the tests are updated and such, that would likely be a welcome contribution. (Likely it’s already been done, but I didn’t check)