api - REST API：如何根据运行时应用程序状态管理同一资源的不同表示？

我的问题用一个小例子解释得最好。

假设我们正在构建一个简单的 Web 应用程序来实时监控火车行程。每次火车在火车站停靠时，火车的当前位置都会由火车司机手动记录。

有一种资源称为/journeys和一种称为/drivers。在此示例中，驾驶员负责管理特定旅程。/journeys火车司机使用对资源的 POST 请求创建旅程。他返回 id 为 15 的旅程。司机需要/journeys/15多次更新资源以记录火车站的每一站。

资源旅程和资源驱动程序（旅程 -> 驱动程序）之间的关系一直保持到火车的旅程最终结束。那是火车到达目的地的时候。之后，将保留有关旅程的信息以供进一步分析。在这部分，关于谁是驱动程序的信息不再重要。

现在我的问题是：根据特定旅程的状态，id 为 15 的资源有两种略有不同的表示。一种具有关系旅程 -> 驱动程序，另一种没有任何关系。应该避免这样的资源设计还是这样的设计常见做法？在我看来，这样的设计可能会导致混乱。

在这个示例中，拥有两个单独的资源会更好吗，例如为了避免混淆并将实时应用程序状态和业务视图状态分开/live/journeys？/analytics/journeys

标签： apirestweb-applications

应该避免这样的资源设计还是这样的设计常见做法？

没关系。

将“资源”想象成一个网页。 GET /journeys/15返回一个文档，该文档是旅程的 HTML 表示形式。当驱动程序报告事件时，文档会更新以匹配。“旅程结束”事件会删除文档中包含的有关驾驶员的信息。

这完全正常。

人类在处理这种模糊性方面做得很好，但对于机器，我们可能希望有一个更明确的模式。对于这个设计，这将包括如何解释文档以提取各种信息的描述，以及哪些信息元素是可选的。

在此示例中，如果有两个单独的资源，例如 /live/journeys 和 /analytics/journeys 以避免混淆并将实时应用程序状态和业务视图状态分开，会更好吗？

让我们从“合理吗？”开始。是的。资源模型可能有许多具有公共信息的资源。作为一个类比，您可能会考虑由对同一数据集的查询生成的两个不同的报告。每个报告都有不同的资源是完全正常的设计。

它更好吗？“这取决于”。多个资源描述相同信息的潜在问题是两个资源的缓存副本可能不同步。通用组件（如 Web 缓存）不一定知道资源是相关的，尤其是不会知道驱动程序更新时需要失效的所有资源/journeys/15

对于在旅程完成之前没有人可能查看分析资源的域，同步可能不是一个大问题，因此多个资源应该没问题。