django - 将 REST 和 RPC 混合在一起是不好的做法吗？

Question

我对 REST Web 服务相当陌生，并且非常习惯 RPC。通过阅读 this 等几篇文章，我了解了 REST 的优势一个。

我正在使用 django-rest-framework 在 django 中开发服务器。

虽然有这个问题(或多个问题):

我有这个模型:

class Poll(models.Model):
    questionString = models.CharField(max_length=500, blank=True)
    timeToAnswer = models.IntegerField(default=30)
    startDate = models.DateTimeField(null=True, db_column='startDate', blank=True)
    token = models.CharField(max_length=20, blank=True, unique=True)

class PollAggregator(models.Model):

    name = models.CharField(max_length=135)
    description = models.CharField(max_length=500, blank=True)
    votersToken = models.CharField(max_length=20, null=True, blank=True)

class PollPollAggregatorRel(models.Model):
    pollAggregator = models.ForeignKey(PollAggregator, null=True, db_column='pollAggregatorId', blank=True)
    poll = models.ForeignKey(Poll, null=True, db_column='pollId', blank=True)

所以我可以进行一次民意调查，也可以在民意调查聚合器(即房间)中聚合一堆民意调查。

所以我创建了其余的调用:pollList、pollDetail、pollAggregatorList、pollAggregatorDetail。但我在设计 PollPollAgregatorRel 时遇到问题。当然，我可以拥有 PollPollAgregatorRelList 和 PollPollAgregatorRelDetail 并进行正常的发布、获取、更新、删除。因此，如果我想以 REST 风格在民意调查和民意调查聚合器之间建立新的关系，我会这样做:

• 通过 get 方法检查 PollPollAgregator(列表)是否存在，并通过 pollId 进行过滤
• 如果是这样，我会更新此项目以获取新的 pollAggregator ID
• 如果没有，我会创建一个带有帖子的新 PollPollAgregator

我的第一个问题是有没有更简单的方法来做到这一点？

如果我使用类似 RPC 的 Web 服务，我会执行以下操作:

• 将 poll 与 pollAggregator 关联起来，并为 PollPollAggregatorRel 使用 get_or_create。因此，我更新或创建一个新的 PollPollAggregatorRel 对象。

因此，使用类似 RPC 的方式，客户端仅使用一次调用，而 REST 则需要调用 2 次。在这种情况下，在服务器端和客户端使用 RPC 似乎要简单得多。

第二个问题是:在同一个 API 中同时使用 REST 和 RPC 是不是不好的做法？

Answer 1

Q1:我认为提供一种 REST 风格的 POST 操作是合理的，该操作要么返回现有的聚合器，要么根据需要创建一个新的聚合器。从逻辑上讲，这似乎与您的“RPC”服务没有什么不同。

我认为您的部分困难可能是您正在设计的 REST“调用”(提示:它们不是“调用”，它们是“资源”)过于紧密地围绕底层模型。这是我过去犯过的错误。

休息!=增删改查。

REST 的一个主要优点是它允许接口(interface)与模型分离，因此服务器可以更改其实现而不影响客户端。另一个主要好处是，它最大限度地减少了客户端执行某些操作所需提前了解的信息量。例如。 REST 客户端应该能够通过与服务的“前端资源”(类似于“前端页面”)交互来发现它需要使用的所有资源 URI。

因此，我会考虑一种方法，其中以下资源涵盖您上面描述的内容:

1. 服务主页，其表示形式包含指向其他资源的链接(或链接模板)(或通过 HTTP 链接 header 返回链接)

2. “民意调查集合”资源，用于创建和访问各个民意调查(例如 GET 返回所有民意调查列表，POST 创建新民意调查)

3. 个人民意调查，其 URI 通过与“民意调查集合”交互而被发现。 GET、PUT、DELETE 按照您的预期进行。我不确定您是否需要 POST 来处理这些。

4. 一种将民意调查与聚合关联起来的“聚合管理器”资源(一项民意调查可以属于多个聚合吗？ - 您的描述表明不能)。对包含 POLL URI 的资源的 POST 可以定位或创建一个聚合(或多个聚合？)或创建一个新的聚合。 GET 可能会返回现有聚合的列表。

5. 通过与聚合管理器资源交互来发现其 URI 的各个聚合资源。

在您的描述中，PollPollAggregatorRel 是您(当前)实现的一部分，而不是您通过 REST API 公开的内容。这使您可以灵活地更改内部实现，而不会影响客户端使用 API 的方式。这就是休息的意义。

我不确定您是否认为这“更容易、更简单”，但这不是 REST 的重点。 Roy Fielding 将 REST 描述为“数十年规模的软件工程”，其要点是创建一个允许客户端和服务器实现相对独立发展的接口(interface)，这对于在 Web 规模上运行的应用程序至关重要。为此需要付出代价，即客户端必须与服务器交互才能发现进行交互所需的信息。

问题 2:我认为在同一个 API 中混合 REST 和 RPC 并不明智。。 (将 REST 暴露给外部客户端并在内部使用 RPC，或者提供单独的 API 可能是非常有意义的。)

我这样做的理由是，如果您主要使用 REST API，那么添加 RPC 元素可能会在客户端和服务器之间创建紧密耦合，从而否定了使用 REST 的初衷。