Creating API Endpoints with Django REST Framework Views

1. The Two Main Approaches to Building Views in DRF

When building views in Django REST Framework, you have a spectrum of choices that balance control and convenience. For this lesson, we'll focus on two key points on that spectrum:

• APIView: A class-based view that gives you full control. You explicitly define how your view responds to each HTTP method (GET, POST, PUT, DELETE). It's great for custom endpoints that don't map directly to a model's CRUD operations.
• Generic Views: A set of pre-built views that provide common functionality for CRUD (Create, Retrieve, Update, Delete) operations. They drastically reduce boilerplate code for standard API endpoints, embodying the "Don't Repeat Yourself" (DRY) principle.

This diagram shows how different view types in DRF relate, with "Ease of use" increasing as you move towards more abstract, specialized views. We'll be focusing on APIView and the Concrete APIView classes.

2. The Ground Floor: Building with APIView

Let's start by building our task endpoints using APIView. This approach requires more code, but it makes the process very clear, as you have to wire everything up yourself.

In APIView, you create a class that inherits from rest_framework.views.APIView, and then you add methods that match the names of the HTTP methods you want to handle, like get(), post(), put(), and delete().

To see how this works in practice, let's watch a demonstration.

Now, let's apply this to our Task Manager project. Open your api/views.py file and add the following code. Remember to import your Task model and TaskSerializer.

# api/views.py
from rest_framework.views import APIView
from rest_framework.response import Response
from rest_framework import status
from django.http import Http404

from tasks.models import Task
from .serializers import TaskSerializer

# View for listing all tasks and creating a new one
class TaskList(APIView):
    """
    List all tasks, or create a new task.
    """
    def get(self, request, format=None):
        tasks = Task.objects.all()
        serializer = TaskSerializer(tasks, many=True)
        return Response(serializer.data)

    def post(self, request, format=None):
        serializer = TaskSerializer(data=request.data)
        if serializer.is_valid():
            serializer.save()
            return Response(serializer.data, status=status.HTTP_201_CREATED)
        return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)

# View for retrieving, updating, or deleting a single task
class TaskDetail(APIView):
    """
    Retrieve, update or delete a task instance.
    """
    def get_object(self, pk):
        try:
            return Task.objects.get(pk=pk)
        except Task.DoesNotExist:
            raise Http404

    def get(self, request, pk, format=None):
        task = self.get_object(pk)
        serializer = TaskSerializer(task)
        return Response(serializer.data)

    def put(self, request, pk, format=None):
        task = self.get_object(pk)
        serializer = TaskSerializer(task, data=request.data)
        if serializer.is_valid():
            serializer.save()
            return Response(serializer.data)
        return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)

    def delete(self, request, pk, format=None):
        task = self.get_object(pk)
        task.delete()
        return Response(status=status.HTTP_204_NO_CONTENT)

Finally, let's create a urls.py file inside your api app directory and wire up these views.

# api/urls.py
from django.urls import path
from . import views

urlpatterns = [
    path('tasks/', views.TaskList.as_view(), name='task-list'),
    path('tasks/<int:pk>/', views.TaskDetail.as_view(), name='task-detail'),
]

Don't forget to include these URLs in your main project's urls.py file.

While APIView works perfectly, you can see there's a lot of repeated logic for getting an object, serializing it, checking if it's valid, and saving it. This is where generic views shine.

3. The Fast Lane: Building with Generic Views

Generic views are designed to eliminate the boilerplate code we just wrote. They provide the core implementation for standard CRUD patterns, so you only need to tell them which model and serializer to use.

Let's explore this powerful feature.

The article highlights that for most standard API endpoints, concrete generic views are the "sweet spot." They combine the GenericAPIView base class with various "mixin" classes that provide the list, create, retrieve, update, and destroy actions.

Let's see a practical refactoring from function-based views to generic views. The principle is the same as refactoring from our APIView.

Inspired by this, let's refactor our api/views.py. You can comment out the APIView classes we wrote and replace them with this much shorter version:

# api/views.py (Refactored with Generic Views)
from rest_framework import generics
from tasks.models import Task
from .serializers import TaskSerializer

class TaskListCreate(generics.ListCreateAPIView):
    queryset = Task.objects.all()
    serializer_class = TaskSerializer

class TaskRetrieveUpdateDestroy(generics.RetrieveUpdateDestroyAPIView):
    queryset = Task.objects.all()
    serializer_class = TaskSerializer

And update your api/urls.py to point to the new view names:

# api/urls.py (Updated)
from django.urls import path
from . import views

urlpatterns = [
    path('tasks/', views.TaskListCreate.as_view(), name='task-list-create'),
    path('tasks/<int:pk>/', views.TaskRetrieveUpdateDestroy.as_view(), name='task-retrieve-update-destroy'),
]

That's it! With just a few lines of code, you have fully functional CRUD endpoints for your Task model. All the logic we wrote manually in APIView is handled for you by ListCreateAPIView and RetrieveUpdateDestroyAPIView. This is the power and efficiency you'll leverage for your portfolio project.

Conclusion

You've made excellent progress today! You've learned how to create API endpoints using two different but related methods, giving you both a deep understanding and a fast, practical toolset.

Key Takeaways:

• APIView is your tool for full control. You define get, post, put, etc., methods to handle HTTP requests manually. It's best for custom logic that doesn't fit the standard CRUD pattern.
• Generic Views (like ListCreateAPIView) are your tool for speed and convention. You simply specify a queryset and serializer_class, and DRF handles all the standard CRUD logic for you.
• For most standard API development, start with Generic Views. They provide the perfect balance of power and simplicity, allowing you to build robust APIs quickly.

Preview of the Next Lesson:

We can make our view code even more concise. In the next lesson, we will explore ViewSets and Routers. ViewSets allow you to combine the logic for both list and detail views into a single class, and Routers can automatically generate the URL patterns for you, further reducing boilerplate and speeding up development.