When building APIs using Django REST Framework (DRF), it's important to control how data is exposed and accepted. You may want certain fields to be visible in the response but not accepted in a request — or vice versa.

That’s where read-only and write-only fields come in.

What Are Read-only and Write-only Fields?

• Read-only fields:
  These appear in serialized output (e.g., GET responses) but are ignored in input (e.g., POST/PUT requests).

• Write-only fields:
  These are accepted in incoming data (POST/PUT requests) but are excluded from responses (GET responses).

Why Use Them?

Here are some common use cases:

How to Define Read-only/Write-only Fields

Method 1: Field arguments

from rest_framework import serializers

class UserSerializer(serializers.Serializer):
    username = serializers.CharField()
    password = serializers.CharField(write_only=True)
    date_joined = serializers.DateTimeField(read_only=True)

Method 2: extra_kwargs in ModelSerializer

class UserSerializer(serializers.ModelSerializer):
    class Meta:
        model = User
        fields = ['id', 'username', 'password', 'date_joined']
        extra_kwargs = {
            'password': {'write_only': True},
            'date_joined': {'read_only': True}
        }

Example: Register Serializer with Password

class RegisterSerializer(serializers.Serializer):
    username = serializers.CharField()
    email = serializers.EmailField()
    password = serializers.CharField(write_only=True)
    token = serializers.CharField(read_only=True)

    def create(self, validated_data):
        user = User.objects.create_user(
            username=validated_data['username'],
            email=validated_data['email'],
            password=validated_data['password']
        )
        user.token = "generated-token"
        return user

Response:

{
  "username": "john",
  "email": "[email protected]",
  "token": "generated-token"
}

Request:

{
  "username": "john",
  "email": "[email protected]",
  "password": "securepassword"
}

Note: The password is accepted in the request but not returned. The token is returned but not required in the request.

Tips & Best Practices

• ✅ Use write_only=True for any sensitive input (like passwords, PINs, etc.).

• ✅ Use read_only=True for fields the client should not modify (like id, timestamps).

• ✅ Combine extra_kwargs and direct field definitions as needed.

• ✅ Don't return sensitive information — validate but keep it private.

⚠️ Common Pitfalls

Final Thoughts

Using read_only and write_only fields in DRF serializers gives you precise control over how data flows in and out of your API. It helps protect sensitive information, prevents misuse of API endpoints, and keeps your application logic clean and secure.

Whether you're handling user registrations, passwords, tokens, or metadata — mastering these serializer options is essential for robust API design.