Building a Context-Aware Job Listing in Django REST Framework
One lesson I've learned while building my Placement Portal is that APIs shouldn't simply expose database records.
They should return information that is meaningful to the user making the request.
Today's feature focused on improving the student job listing.
Instead of showing every job as a static record, the API now tells each student whether they have already applied for that job.
The Problem
A traditional job listing API simply returns data stored in the Job table.
For example:
- Job Title
- Company
- Description
- CTC
Although this information is useful, it doesn't answer one important question for the student:
"Have I already applied for this job?"
Without that information, the frontend would need to make additional API calls or perform extra logic to determine the application status.
I wanted the API to provide that answer directly.
The Solution
Instead of storing an application status inside the Job model, I calculate it dynamically.
The relationship already exists in another table:
Application
This model connects:
- Student
- Job
- Application Status
Whenever a student applies for a job, the corresponding record is created or updated in the Application table.
Rather than duplicating this information, the job listing API reads it when serializing each job.
Using SerializerMethodField
To achieve this, I used Django REST Framework's SerializerMethodField.
A custom serializer method computes a new field called status.
Whenever the serializer processes a job object, it:
- Identifies the authenticated student.
- Searches the
Applicationtable for that student and job. - Returns the appropriate status.
For example:
- Not Applied
- Applied
- Rejected
- Placed
The status isn't stored in the Job table—it is computed based on the relationship between the authenticated user and the job.
Why Compute Instead of Store?
One of the principles I try to follow is avoiding duplicated data.
If application status already exists in the Application model, storing the same information inside the Job model would introduce unnecessary redundancy.
By computing the value during serialization:
- The data remains consistent.
- The API becomes more informative.
- The frontend receives everything it needs in a single response.
Improving the User Experience
From the student's perspective, the difference is subtle but valuable.
Instead of seeing only available jobs, they immediately know whether they have:
- Not applied
- Already applied
- Been rejected
- Been placed
The frontend doesn't need additional requests to determine this information.
The API delivers a response tailored to the authenticated user.
Lessons Learned
Building APIs has taught me that serialization is about more than converting database objects into JSON.
It's an opportunity to shape data into something meaningful for the client.
By combining relational data with SerializerMethodField, the job listing became personalized without complicating the frontend.
As I continue building this Placement Portal in public, I'm discovering that many improvements come from making APIs smarter rather than making the frontend more complex.