模型,视图或序列化程序是否代表Django Rest Framework中的REST资源?

问题描述

我正在使用Django Rest Framework构建API,并且试图使其尽可能地具有RESTful风格。在this question(还有this question on SoftwareEngineering)之后,我描述了我的API端点将公开的许多资源,例如可以在以下URL上看到的Invoice:{{1 }}

但是,我在将RESTful设计原则与Django Rest Framework的具体工作联系起来时遇到了麻烦。我不清楚什么构成资源 :模型,序列化器还是视图?

尤其是,我对实现我的/api/v1/invoices/<invoicenumber>/方法的正确位置感到困惑。在常规的Django应用程序中,它肯定会存在于Invoice模型中:

calculate_total()

尽管实际计算可能很复杂,但“总计”在概念上是发票表示的一部分。从这个意义上讲,资源更等效于class InvoiceModel(models.Model): def calculate_total(self): # do calculation return total

InvoiceSerializer

最后,资源将始终由视图访问。因此,您还可能认为视图实际上是资源,而序列化器和模型只是实现细节:

class InvoiceSerializer(serializers.Serializer):
    total = serializers.SerializerMethodField()

    def get_total(self,obj):
        # do calculation
        return total

如果我必须将上述类别之一指定为作为资源的发票的规范表示形式,那将是哪一个?我应该在模型类,序列化器类还是视图类上实现我的方法?抑或是我想得太多了,他们中的任何一个都会做?

解决方法

好吧,尽管我同意可能会有不同的解决方案,但在这种情况下,我肯定会选择该模型。作为功​​能的资源和放置位置。

对于该功能,甚至可以将其实现为发票的计算属性。实际上,对我来说,TOTAL看起来更像是方法的属性。

无论如何,我的思路以及如何使用其他两个选项(序列化器和视图)对我来说都很有趣。

我认为该模型绝对是一种资源。在我这种情况下,发票资源就是模型。因此,我想说您的API将要发布的每个模型都是一种资源。

我还认为,只要资源与单个模型不直接相关,就可以将视图视为资源。

现在,序列化器对我来说是个谜。我想不出是可以将其视为资源的情况。

相关问答

依赖报错 idea导入项目后依赖报错,解决方案:https://blog....
错误1:代码生成器依赖和mybatis依赖冲突 启动项目时报错如下...
错误1:gradle项目控制台输出为乱码 # 解决方案:https://bl...
错误还原:在查询的过程中,传入的workType为0时,该条件不起...
报错如下,gcc版本太低 ^ server.c:5346:31: 错误:‘struct...