00:00 In the previous lesson, I showed you how to use permissions with the DRF. In this lesson, I’m going to show you how to use serializers that are not associated with a Django model. Up until now, all of the serialization that I’ve shown you has been associated with a Django database ORM object. You don’t have to do that.
You can create a serializer from scratch, and it doesn’t have to serialize something from Django. You do this by inheriting from the
serializers.Serializer class and combine it with serializer fields.
In this lesson and the next lesson, I’m going to use the same app, which is a new one called
vehicles. Like always, if you’re coding along with me, you’ll need to add
vehicles to your
You’ll need to update your
urls file to include
vehicle.urls to pull in anything defined there. And then follow along with any models, serializers, views, and urls that I show you. For this particular lesson, there won’t be anything to migrate.
Because I’m going to be using the same
vehicles app in this lesson and in the next lesson and I’m going to be creating multiple models, in order to be a little more organized, I’m going to switch over from using a
models.py file to a
There’s one extra step that you have to do to get all this to work, which I’ll show you in a second. Inside of the
models/ directory, I’ve created a file called
tools.py, and inside of that I’m creating a regular old Python object.
Here’s my generic serializer. Notice that it’s inheriting from just
Serializer instead of
ModelSerializer. I’m specifying each of the fields that I’m going to serialize, and I specify one field for each of the attributes of the
Continuing on with the pattern, I’ve created a
views/ directory and inside of that, I’ve created
tools, I’m creating a single view that just lists the tools to give you the idea of how this serialization works. On line 8, I’m using the
@api_view decorator in the exact same way as one of the early lessons. And line 9, I’m creating the definition of the
list_tools() view. Line 10 through 13, I’m creating two
These are just generic Python classes that have been instantiated as
"wrench". From line 15 on, this method is no different than when it is a Django object being serialized. You create the serializer, you pass in the thing being serialized—in this case, a list of the
04:38 It doesn’t have to be a Django object. This gives you a fair amount of power. You can serialize the things in your database, or, if you want, you can create your own as needed by your application.
Most of these are similar, what changes is the validation. So for example, the
IPAddressField is still just a string, but the validator makes sure that the string is formatted as a valid IP address.
There are fields for uploaded files, composite fields, which hold groupings of other things like dictionaries or nested JSON, and specialty fields like
HiddenField for your forms, or the
SerializerMethodField, which is a special field that is read-only that gets mapped to a method inside of the serializer. Every time the field is serialized, that method gets called, which allows you to run arbitrary code anytime serialization happens.
When you instantiate a field, you can pass it arguments to control how it behaves. Some of the arguments are whether or not the field is read-only, write-only, required, what its default value is, whether it allows null, what the source attribute of the field is. By default, the
Serializer class uses the name of the field to look up the corresponding field in the object being serialized. If you need to rename this, or there’s a reason that mapping won’t work for you, the
source argument allows you to specify where to look something up.
You can specify validators, similar to Django’s model validators, that determine whether or not the values in the field being serialized are valid. And then finally,
style are all arguments you can use to specify the presentation. Some of these are specific to certain kinds of renderers.
For example, if you were using the HTML renderer, the
style argument can pass in CSS information to tell the template how to style the field being rendered. As you’ve probably surmised, the
ModelSerializer that I’ve been using up until now is built based on top of all these concepts that are already here.
Serializer is the beating heart of the DRF—it’s all about how you get that payload and how you use it. For more information on how fields work and how to use the arguments that go with them, see the fields section of the API guide.
Become a Member to join the conversation.