DRF非模型Serializer实现POST数据上传解析存储：create()与to_internal_value()选型及验证方案咨询

Hey there! Let's walk through the best way to implement your API endpoint requirements, step by step.

We'll split this into three key parts: validating your input data (including checking for the existence of the ID in the database), choosing the right method to run your parsing logic, and putting it all together with a clean implementation.

You need two types of validation here:

• Field format validation: Your serializer's field definitions already cover this! The IntegerField ensures id is a number, and CharField(required=True, allow_null=False) makes sure config and hash are non-null strings.
• Existence check for the ID: Add a custom validation method to your serializer to verify the corresponding object exists in the database.

Here's how to implement the ID validation:

def validate_id(self, value):
    # Replace MyModel with your actual model name
    if not MyModel.objects.filter(id=value).exists():
        raise serializers.ValidationError(f"No object found with ID {value}")
    return value

This method runs automatically during the serializer's validation flow, so invalid IDs will return a clear error response before any parsing or database operations happen.

Let's clarify the roles of these two methods to make the right choice:

• to_internal_value(): This method's job is to convert raw input data (like the JSON from your POST request) into Python objects/values that the serializer can work with. It's meant for data transformation, not business logic or database operations. You shouldn't write to the database here—it's a side effect that violates the method's intended purpose.
• create(): This is the correct place for your parsing and database storage logic. When you call serializer.save() in your view, DRF triggers create() (for POST requests) with the already validated data. This method is designed to handle creating and saving objects to the database.

So go with create() for your parse_data call and persistence logic.

Here's the complete serializer with validation, parsing, and database storage:

from rest_framework import serializers
from .models import MyModel, ParsedResult  # Adjust these to your actual models

# Your custom parsing function
def parse_data(obj_id, config_str, hash_str):
    # Add your actual parsing logic here
    # Example: parse config into structured data, verify hash, etc.
    parsed_output = {
        "related_object_id": obj_id,
        "processed_config": config_str.strip(),  # Dummy parsing step
        "hash_valid": hash_str.startswith("valid_")  # Dummy hash check
    }
    return parsed_output

class MyConfigUploadSerializer(serializers.Serializer):
    id = serializers.IntegerField(required=True)
    config = serializers.CharField(required=True, allow_null=False)
    hash = serializers.CharField(required=True, allow_null=False)

    def validate_id(self, value):
        if not MyModel.objects.filter(id=value).exists():
            raise serializers.ValidationError(f"Object with ID {value} does not exist")
        return value

    def create(self, validated_data):
        # Extract validated values
        obj_id = validated_data["id"]
        config = validated_data["config"]
        hash_val = validated_data["hash"]

        # Run your custom parsing
        parsed_result = parse_data(obj_id, config, hash_val)

        # Save parsed result to the database
        return ParsedResult.objects.create(**parsed_result)

Then, in your view (a simple CreateAPIView works here):

from rest_framework import generics
from .serializers import MyConfigUploadSerializer

class ConfigUploadView(generics.CreateAPIView):
    serializer_class = MyConfigUploadSerializer

This setup ensures:

• Input data is validated (format + ID existence) before any parsing
• Parsing logic runs only on valid data
• Database operations are handled in the appropriate DRF method, keeping your code clean and maintainable

内容的提问来源于stack exchange，提问作者Empusas