REST API：如何根据运行时应用程序状态管理同一资源的不同表现形式？
REST API: How to manage different representations of the same resource based on runtime application state?
我的问题用一个小例子解释得最好。
假设我们正在构建一个简单的 Web 应用程序来监控 real-time 中的火车行程。每次火车停在火车站时，火车的当前位置由火车的driver手动记录。
有一项资源名为 /journeys，一项名为 /drivers。在此示例中，driver 负责管理特定旅程。火车 driver 创建了一个旅程，其中包含对 /journeys 资源的 POST 请求。他返回了一个 ID 为 15 的旅程。driver 需要多次更新资源 /journeys/15 以记录火车站的每一站。
资源旅程和资源drivers（旅程-> drivers）之间的关系一直保持到火车旅程最终结束。那是火车到达目的地的时候。之后，将保留有关旅程的信息以供进一步分析。在这部分，关于谁是driver的信息已经不重要了。
现在回答我的问题： 根据特定旅程的状态，id 为 15 的资源有两种略有不同的表示形式。一种是关系旅程 -> drivers和one没有任何关系。应该避免这样的资源设计还是这种设计是常见的做法？在我看来，这样的设计可能会导致混淆。
在此示例中，使用两个单独的资源（例如 /live/journeys 和 /analytics/journeys 以避免混淆并将实时应用程序状态和 business-view 状态分开会更好吗？
Should a resource design like this be avoided or is such a design common practice?
没关系。
将“资源”想象成一个网页。 GET /journeys/15 returns 一份文档，它是对旅程的 HTML 表示。当 driver 报告事件时，文档会更新以匹配。 “旅程结束”事件删除了文档中包含的有关 driver 的信息。
这很正常。
人类可以很好地处理这种歧义，但对于机器，我们可能希望有一个更明确的模式。对于此设计，这将包括如何解释文档以提取各种信息的描述，以及哪些信息元素是 可选。
Would it be better in this example to have two seperate resources, such as /live/journeys and /analytics/journeys to avoid confusion and to seperate live application state and business-view state?
让我们从“合理吗？”开始。是的。资源模型可能有许多具有公共信息的资源。作为类比，您可能会考虑对同一数据集的查询生成的两个不同的报告。每个报告都有不同的资源是完全正常的设计。
更好吗？ “这取决于”。多个资源描述相同信息的潜在问题是这两个资源的缓存副本可能不同步。通用组件（如网络缓存）不一定知道资源是相关的，尤其是当 driver 更新 /journeys/15[= 时，不会知道所有需要失效的资源14=]
对于一个在旅程结束之前没有人可能会查看分析资源的域，同步可能不是一个大问题，因此多个资源应该没问题。
我的问题用一个小例子解释得最好。
假设我们正在构建一个简单的 Web 应用程序来监控 real-time 中的火车行程。每次火车停在火车站时，火车的当前位置由火车的driver手动记录。
有一项资源名为 /journeys，一项名为 /drivers。在此示例中，driver 负责管理特定旅程。火车 driver 创建了一个旅程，其中包含对 /journeys 资源的 POST 请求。他返回了一个 ID 为 15 的旅程。driver 需要多次更新资源 /journeys/15 以记录火车站的每一站。
资源旅程和资源drivers（旅程-> drivers）之间的关系一直保持到火车旅程最终结束。那是火车到达目的地的时候。之后，将保留有关旅程的信息以供进一步分析。在这部分，关于谁是driver的信息已经不重要了。
现在回答我的问题： 根据特定旅程的状态，id 为 15 的资源有两种略有不同的表示形式。一种是关系旅程 -> drivers和one没有任何关系。应该避免这样的资源设计还是这种设计是常见的做法？在我看来，这样的设计可能会导致混淆。
在此示例中，使用两个单独的资源（例如 /live/journeys 和 /analytics/journeys 以避免混淆并将实时应用程序状态和 business-view 状态分开会更好吗？
Should a resource design like this be avoided or is such a design common practice?
没关系。
将“资源”想象成一个网页。 GET /journeys/15 returns 一份文档，它是对旅程的 HTML 表示。当 driver 报告事件时，文档会更新以匹配。 “旅程结束”事件删除了文档中包含的有关 driver 的信息。
这很正常。
人类可以很好地处理这种歧义，但对于机器，我们可能希望有一个更明确的模式。对于此设计，这将包括如何解释文档以提取各种信息的描述，以及哪些信息元素是 可选。
Would it be better in this example to have two seperate resources, such as /live/journeys and /analytics/journeys to avoid confusion and to seperate live application state and business-view state?
让我们从“合理吗？”开始。是的。资源模型可能有许多具有公共信息的资源。作为类比，您可能会考虑对同一数据集的查询生成的两个不同的报告。每个报告都有不同的资源是完全正常的设计。
更好吗？ “这取决于”。多个资源描述相同信息的潜在问题是这两个资源的缓存副本可能不同步。通用组件（如网络缓存）不一定知道资源是相关的，尤其是当 driver 更新 /journeys/15[= 时，不会知道所有需要失效的资源14=]
对于一个在旅程结束之前没有人可能会查看分析资源的域，同步可能不是一个大问题，因此多个资源应该没问题。