このリンク を参照して、Django Rest FrameworkでHyperlinkedModelSerializerを使用する例がたくさんあります。
HyperlinkedModelSerializerクラスは、プライマリキーではなくハイパーリンクを使用してリレーションシップを表すことを除いて、ModelSerializerクラスに似ています。
私の質問は、それらを通常のモデルシリアライザーと比較して使用する場合のユースケース/利点は何ですか?
唯一の違いは、引用したように、主キーと外部キーは、実際のキー値ではなく、それらのリソースを指すURLで表されることです。
利点は、関連オブジェクトを取得するときに、フロントエンドでリソースURLを構築する必要がないことです。
もう1つは、ネストされた表現です。これにより、シリアライザー出力で関連オブジェクトをインライン化できます。これは、APIコンシューマーが関連するアイテムを取得するために追加のリクエストを行うよりもすぐに便利な場合、ModelSerializer
とHyperlinkedModelSerializer
の両方と組み合わせることができます。
ネストされた表現は、Meta.depth
オプションを介して、またはRelatedField
の代わりに関連モデルのシリアライザーを使用して実装できます。
@xleonがコメントで述べたように、URLをキーとして使用すると、他の開発者がAPIを理解しやすくなります。
Web APIデザインでエンティティ間の関係を実装する必要があります。それを行うにはいくつかの方法があります(DRFのドキュメントに関する言及)。
HyperlinkedModelSerializerには、ModelSerializerとは次の違いがあります。
簡単な例:
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:yourpassword 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"
}
]
しかし、あなたが変更した場合
class UserSerializer(serializers.ModelSerializer):
class Meta:
model = User
fields = ('url', 'username', 'email', 'groups')
結果は次のようになります。
"results": [
{
"email": "[email protected]",
"groups": [
1,
2
],
"url": "http://127.0.0.1:8000/users/1/",
"username": "admin"
}
]
注意すべきHyperlinkedModelSerializersの1つのコストは、APIがURLのクエリパラメーターによるフィルタリングまたは順序付けをサポートしている場合、フロントエンドコンシューマーがハイパーリンクURLフィールドを使用してクエリパラメーターを構築するのが少し難しいことです。 pkを直接使用可能にするのではなく、URLからpkを使用します。
たとえば、/api/objects/12/
にあるルート上のオブジェクトを想定すると、コンシューマはurl
フィールドを解析して12
を抽出し、別のエンドポイントでこのオブジェクトによるフィルタリングを構築する必要があります。 /api/otherobjects/?object=12
。大きな問題ではありませんが、大量のフィルタリングを行う予定がある場合は残念です。