我正在尝试首次开发REST API，在我看来，我在实现一些基本REST API概念时遇到了问题。我不确定是否只为每个模型创建CRUD操作，然后使用Vue分析这些操作的响应（在我的情况下）？还是应该让我的DRF一方做一些业务逻辑？
具体问题 这是一个例子。我想删除一个对象并更新其他表中的其他一些对象，这些对象与我要删除的原始对象有关。我应该只是创建一个POST（？）端点来执行此操作，还是应该使用Vue获取要删除的其他对象，然后从Vue中对每个对象调用“删除”，然后才删除原始对象。如您所见，在第一种情况下，它是一个复杂的操作，在第二种情况下，它是几个CRUD操作。
之所以问这个问题，是因为我在Google中找到了许多REST API的解释，而我很难找到真相。在我看来，DRF不想让我创建复杂的视图，看起来它只是希望我为每个模型创建4个操作。 希望我能说清楚，谢谢您的帮助。
答案 0 :(得分：0)
您似乎真正要问的是，哪种耦合程度适合REST API。答案是尽可能的少，但是可行的方法取决于您的应用程序和您的要求。
使用您的示例，是的，最好为您的每个资源都提供一个统一的删除接口，但是您还有其他要求吗？如果级联删除子级资源是否有问题？您可以自动删除孤立资源吗？您是否可以通过要求客户端通过他们自己的端点显式删除多个资源来承受失去交易完整性的负担？如果您找不到使统一删除界面为您工作的方法，那么只要创建一个POST端点来执行您需要的操作就不会有错误或不麻烦，只要这不与特定客户端实现的需求挂钩。
不要指望找到“真相”，REST API最佳实践手册或有关此问题的最终答案，因为REST只是一种体系结构样式，而不是一种严格的体系结构规范。这只是用来指导应用程序的长期设计和演进的一组原则。
如果您没有长期要求严格采用REST原则的要求，那么比发现REST的真相更重要的是尊重最小惊讶原则，因为许多人已经对如何REST API应该被实现。一个很好的例子是带有URL的API版本控制。在您的网址中添加版本号是REST的反模式，但许多人认为这是REST的最佳做法，这是一种普遍的做法。发生这种情况是因为大多数所谓的API都与客户端紧密耦合，并且API版本控制使进行向后不兼容的更改变得容易得多。当您正确实现REST API和客户端时，进行向后不兼容的更改不是问题，但是与仅仅在某个地方处理版本号相比，它需要做更多的工作。
如果您确实有长期的要求，或者您真的对学习如何正确设计和实现REST API感兴趣，请尝试搜索“ Hypermedia API”而不是“ REST API”。许多人放弃了REST一词，决定开始使用新术语来指代正确实现REST的API。