在DRF中使用HyperlinkedModelSerializer有什么好处？

Question

在参考this link时，我已经看到很多在Django Rest Framework中使用HyperlinkedModelSerializer的例子。它说：

HyperlinkedModelSerializer类与ModelSerializer类类似，不同之处在于它使用超链接来表示关系，而不是主键。

我的问题是，使用它们与常规模型序列化器的用例/好处是什么？

Answer 1

唯一的区别在于，如您所引用的那样，主键和外键由指向这些资源的URL表示，而不仅仅是实际的键值。

好处是，当您想要检索相关对象时，您不必在前端构建资源URL。

完全另一件事是嵌套表示，它允许您在串行器输出中内联相关对象。当你认为API消费者更方便地拥有相关项目而不是提供额外的检索请求时，可以将它与ModelSerializer和HyperlinkedModelSerializer结合使用。

嵌套表示可以通过Meta.depth选项或使用相关模型的序列化器而不是RelatedField来实现。

正如@xleon在评论中所说的那样，使用URL作为密钥使其他开发人员更容易理解您的API。

Answer 2

我们需要在Web API设计中实现实体之间的关系。有几种方法可以做到这一点（如DRF文档中所述）：

• 使用主键。
• 在实体之间使用超链接。
• 在相关实体上使用唯一标识段塞字段。
• 使用相关实体的默认字符串表示形式。
• 将相关实体嵌套在父表示中。
• 一些其他自定义表示

HyperlinkedModelSerializer与ModelSerializer有以下不同之处：

• 默认情况下，它不包含id字段。
• 它包含一个url字段，使用HyperlinkedIdentityField。
• 关系使用HyperlinkedRelatedField而不是PrimaryKeyRelatedField。

一个简单的例子：

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"
        }
    ]

Answer 3

应该注意的HyperlinkedModelSerializers的一个代价是，如果您的API支持通过URL中的查询参数进行过滤或排序，那么您的前端使用者使用超链接的url字段构建查询参数更加困难，因为他们必须解析来自URL的pk而不是直接使用pk。

例如，假设/api/objects/12/上的路径上的对象，消费者需要解析url字段以提取12，以便在另一个端点上构建此对象的查询过滤：/api/otherobjects/?object=12。这不是一个大问题，但如果你计划进行大量过滤，那就太糟糕了。