Mam interfejs REST API django-rest-framework z zasobami hierarchicznymi. Chcę móc tworzyć podobiekty przez POSTing do /v1/objects/<pk>/subobjects/
i automatycznie ustawić klucz obcy na nowym obiekcie podrzędnym na kwarg z pk
z adresu URL bez konieczności umieszczania go w polu danych. Obecnie serialalizator powoduje błąd 400, ponieważ oczekuje, że klucz obcy object
znajdzie się w polu danych, ale nie powinien być również uważany za opcjonalny. Adres URL podobiektów to /v1/subobjects/<pk>/
(ponieważ klucz rodzica nie jest konieczny, aby go zidentyfikować), więc nadal jest wymagany, jeśli chcę PUT
istniejącego zasobu.Django REST Framework: tworzenie obiektów hierarchicznych za pomocą argumentów URL
Czy powinienem zrobić tak, aby POST na /v1/subobjects/
z rodzica w ładunku, aby dodać podobiekty, czy jest tam czysty sposób przekazać kwarg z pk
z adresu URL do serializera? Używam HyperlinkedModelSerializer
i ModelViewSet
jako moich odpowiednich klas bazowych. Czy jest jakiś zalecany sposób robienia tego? Dotychczas jedynym pomysłem było całkowite ponowne wdrożenie ViewSetów i stworzenie niestandardowej klasy Serializer, której get_default_fields() pochodzi ze słownika, który jest przekazywany z ViewSet, wypełniony przez jego kwargs. Wydaje się to dość zaangażowane w coś, co uważałbym za całkowicie run-of-the-mill, więc nie mogę przestać myśleć, że czegoś brakuje. Każdy interfejs REST API, jaki kiedykolwiek widziałem ma zapisywalne punkty końcowe, ma tego rodzaju oparte na adresie URL argumentowanie, więc fakt, że django-rest-framework nie wydaje się być w stanie to zrobić, wydaje się dziwny.
Funkcja 'pre_save' nie jest wywoływana aż do wystąpienia deserializacji, w którym to momencie wystąpił już błąd sprawdzania poprawności. –
Ah, okay. Odpowiedź zaktualizowana. –
Jest to jedna z opcji i działa na coś w rodzaju komentarzy, ale niektóre z obiektów, które mam, powinny być zdolne do powtórzenia, więc ustawienie rodzica jawnie w PUT byłoby miłe. Z drugiej strony, mógłbym to zrobić w ten sposób, a następnie mieć wyraźną akcję POST typu "reparent" lub coś podobnego, ale wydaje się to trochę mniej restrykcyjne. Przyjmuję tę odpowiedź, ponieważ jest to dobry pomysł i będzie działać w większości przypadków. –