我正在使用Django Rest Framework构建API，并且正在尝试使其尽可能具有RESTful风格。紧接着这个问题（以及这个有关SoftwareEngineering的问题），我描述了我的API端点将公开的许多资源，例如Invoice可以在以下URL中看到的资源：/api/v1/invoices/<invoicenumber>/
但是，我在将RESTful设计原则与Django Rest Framework的具体工作联系起来时遇到了麻烦。我不清楚什么构成资源：模型，序列化器还是视图？
特别是，我对实现我的calculate_total()方法的正确位置感到困惑。在常规的Django应用程序中，它肯定会存在于Invoice模型中：
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
最后，资源将始终由视图访问。因此，您还可能认为视图实际上是资源，而序列化器和模型只是实现细节：
class InvoiceView(APIView):
def calculate_total(self, obj):
# do calculation
return total
如果我必须将上述类别之一指定为作为资源的发票的规范表示形式，那将是哪一种？我应该在模型类，序列化器类还是视图类上实现我的方法？还是我想得太多，而他们中的任何一个都会做呢？
好吧，尽管我同意可能会有不同的解决方案，但在这种情况下，我肯定会选择该模型。作为资源和放置功能的地方。
就功能而言，它甚至可以实现为发票的计算属性。实际上，对我来说，TOTAL看起来更像是方法的属性。
无论如何，对我来说，您的思路以及如何使用其他两个选项（序列化器和视图）似乎都很有趣。
我认为该模型绝对是一种资源。在我这种情况下，发票资源就是模型。因此，我想说您的API将要发布的每个模型都是一种资源。
我还认为，只要资源不与单个模型直接相关，就可以将视图视为资源。
现在，序列化器对我来说是个谜。我想不出一个案例，可以认为它是一种资源。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句