现在我们有了武装路线和观点，我们将了解API的流程。

流

任何用户都应该能够输入网站，移动应用程序甚至桌面应用程序，并选择列表的列表。

为了促进此事，我们将假设它始终是管理用户，这是我们在BD中拥有的第一个。

这种颜色选择意味着/api/colors 。

然后该用户必须选择颜色并投票。这里发生了两件事：原则上，我们必须进行/api/pote/1 才能验证该投票已经存在。在负面案件中，我们将允许您投票；在积极的情况下，我们只允许您看到投票的结果，顺便说一句，这是 api/pote 。

如果我们允许你

{
  "user": 1,
  "color": 1
}

当然，用户和颜色具有用户和颜色的详细信息，因此我们必须通过标识符，我的意思是每个实体的ID。

如果您不知道DRF，则可能认为这些都必须组装它们。远离现实的没有遥远的地方：当我们定义视图集并将它们与路线相关联时，我们有以下预先创建的端点：

• 获得API/票：获得所有选票。
• 获取API/投票/：根据身份证获得投票。
• 发布API/投票/：创建投票。
• put/patch api/pote/：修改整个投票或部分投票。
• DELET API/投票/：根据身份证
取消投票

我们都有颜色的全部，但带有“ API/颜色”。

在更简单的API中，我的工作本来可以完成的：我已经有可以根据颜色进行的投票。

问题是我们在当前流程中有一些故障：

• 我们无法寻找投票的人，因为“获得API/票/”搜索投票ID ，不是因为用户ID。
• 您可以代表任何用户投票，因为“发布API/投票/”允许我们发送我们想要的用户。
• 由于上面的相同原因，可以对任何投票进行编辑或删除。
• 我们可以删除所有颜色并打破选票。因为我们有一个级联，例如，如果我消除了蓝色，并且有50票的选票，他们将被消除。一个严重的问题。

解决方案

幸运的是，视图允许我们

您必须站在中间并条件这些终点，但是以前，您必须通过令牌建立一个身份验证系统来创建会话并通知您所讲的API。

，亲爱的朋友们，我们将在下一篇文章中看到。