2015-10-29 9 views
16

In Bezug auf this link habe ich viele Beispiele für die Verwendung eines HyperlinkedModelSerializer in Django Rest Framework gesehen. Dort heißt es:Welchen Vorteil hat die Verwendung eines HyperlinkedModelSerializers in DRF?

Die HyperlinkedModelSerializer Klasse der ModelSerializer Klasse ähnlich ist, außer dass es Hyperlinks verwendet Beziehungen darzustellen, statt Primärschlüssel.

Meine Frage ist, was ist der Nutzen/Vorteil der Verwendung von ihnen vs einem normalen Model Serializer?

Antwort

16

Der einzige Unterschied besteht darin, dass Primär- und Fremdschlüssel, wie in der Beschreibung enthalten, durch URLs dargestellt werden, die auf diese Ressourcen verweisen, und nicht nur auf tatsächliche Schlüsselwerte.

Der Vorteil ist, dass Sie keine Ressourcen-URLs in Ihrem Frontend erstellen müssen, wenn Sie verwandte Objekte abrufen möchten.

Eine andere Sache ist vollständig verschachtelte Darstellungen, die Ihnen ermöglicht, verwandte Objekte in Ihrer Serializer-Ausgabe zu inline. Dies kann sowohl mit ModelSerializer als auch mit HyperlinkedModelSerializer kombiniert werden, wenn Sie der Meinung sind, dass es für den API-Consumer einfacher ist, verwandte Elemente direkt zu verwenden, anstatt zusätzliche Anforderungen zum Abrufen von ihnen zu stellen.

Verschachtelte Darstellungen können über die Option Meta.depth implementiert werden, oder indem der Serializer des entsprechenden Modells anstelle eines RelatedField verwendet wird.

Da @xleon in seinem Kommentar mit URLs als Schlüssel sagte erleichtert es anderen Entwicklern, Ihre API zu verstehen.

+6

Schöne Antwort, ich würde nur eine Sache hinzufügen: Verwendung von Hyperlinks in Ihren Ressourcen wird es einfacher für jeden Entwickler mit Ihrer Web-API. Wenn sie den gesamten Ressourcen-URI sehen können, brauchen sie keine Dokumentation oder andere Wege, um das herauszufinden. – xleon

4

Wir müssen die Beziehung zwischen Entitäten im Web-API-Design implementieren. Es gibt mehrere Möglichkeiten, das zu tun (wie auf der DRF Dokumentation erwähnt):

  • Mit Primärschlüssel.
  • Verwenden von Hyperlinks zwischen Entitäten.
  • Verwenden eines eindeutigen identifizierenden Slug-Feldes für die zugehörige Entität.
  • Verwenden der Standardzeichenfolgendarstellung der verknüpften Entität.
  • Verschachteln der zugehörigen Entität innerhalb der übergeordneten Repräsentation.
  • Einige andere benutzerdefinierte Darstellung

Die HyperlinkedModelSerializer folgende Unterschiede von ModelSerializer hat:

  • Es beinhaltet nicht die ID-Feld in der Standardeinstellung.
  • Es enthält ein URL-Feld mit HyperlinkedIdentityField.
  • Beziehungen verwenden HyperlinkedRelatedField anstelle von PrimaryKeyRelatedField.

Ein einfaches Beispiel:

class UserSerializer(serializers.HyperlinkedModelSerializer): 
    class Meta: 
     model = User 
     fields = ('url', 'username', 'email', 'groups') 


class GroupSerializer(serializers.HyperlinkedModelSerializer): 
    class Meta: 
     model = Group 
     fields = ('url', 'name') 

bash> http -a Admin: IhrKennwort http://127.0.0.1:8000/users/

"results": [ 
     { 
      "email": "[email protected]", 
      "groups": [ 
       "http://127.0.0.1:8000/groups/1/", 
       "http://127.0.0.1:8000/groups/2/" 
      ], 
      "url": "http://127.0.0.1:8000/users/1/", 
      "username": "admin" 
     } 
    ] 

Aber wenn Sie

class UserSerializer(serializers.ModelSerializer): 
     class Meta: 
      model = User 
      fields = ('url', 'username', 'email', 'groups') 

Das Ergebnis wird zu ändern:

"results": [ 
     { 
      "email": "[email protected]", 
      "groups": [ 
       1, 
       2 
      ], 
      "url": "http://127.0.0.1:8000/users/1/", 
      "username": "admin" 
     } 
    ] 
+0

Klares Beispiel, danke! –

0

Eine Kosten für HyperlinkedModelSerializers, die beachtet werden sollte, ist, dass, wenn Ihre API-Filterung oder Bestellung über Abfrage-Parameter in der URL unterstützt es ein bisschen schwieriger für Ihr Frontend Verbraucher ist die verlinkte URL-Felder für die Konstruktion von Abfrage params zu verwenden, da Sie müssen den PK von der URL aus analysieren, anstatt den PK direkt verfügbar zu haben.

beispielsweise ein Objekt auf einer Strecke in /api/objects/12/ vorausgesetzt der Verbraucher benötigen würde das url Feld zu analysieren, um die 12 zu extrahieren, um eine Abfrage-Filterung von diesem Objekt auf einem anderen Endpunkt zu konstruieren: /api/otherobjects/?object=12. Kein großes Problem, aber ein Mist, wenn Sie viel filtern wollen.

Verwandte Themen