REST 状态代码和最终一致性？答案

【问题标题】：REST status code and eventual consistency?REST 状态代码和最终一致性？
【发布时间】：2014-04-08 10:00:44
【问题描述】：

我有一个在 Google App Engine 上运行的 RESTful Web 服务，并使用 JPA 在 GAE 数据存储中存储实体。

使用 POST 请求创建新实体（因为服务器将生成实体 ID）。

但是，我不确定返回的最佳状态代码，因为 GAE DS 最终是一致的。我考虑了以下几点：

200 OK：RFC 声明响应正文应包含“描述或包含操作结果的实体”。这是可以实现的，因为实体在持久化到 DS 时会使用其生成的 ID 进行更新，因此可以立即序列化并返回更新的实体。但是，随后按 ID 对该实体的 GET 请求可能会失败，因为所有节点可能尚未达到一致性（这已被视为我的客户端应用程序的现实问题）。
201 Created：如上所述，如果尚未达到一致性，则返回新实体的 URI 可能会导致客户端出现问题。
202 已接受：将消除上述问题，但无法告知客户新实体的 ID。

在这种情况下什么是最佳实践？

【问题讨论】：

【解决方案1】：

按键获取始终是一致的，因此根据您的标准，200 响应将是好的，除非在谷歌土地上存在问题。您确定您观察到的问题来自获取而不是查询。选择 KEY 的查询与按键 GET 的查询是有区别的。

要使查询保持一致，它必须是祖先查询，或者 GET 是一致的，因为索引尚未更新，其他任何东西都可能看到不一致的数据。

这一切都假设在谷歌土地上没有实际问题。过去我们已经看到过一些问题，即数据中心延迟复制和最终一致性的时间很晚，有时甚至是几个小时。

但你无法知道这一点，所以你要么必须假设一切都好，要么采取极其悲观的态度。

【讨论】：

他在问题中说 GET 在现实世界中有时会失败。这就是他问这个问题的原因。
但它真的是来自获取还是查询。我唯一知道失败的时间是谷歌中断时。这是您可以处理的事情吗，在那个级别上使用响应代码。两种方式你都不知道。这意味着您永远不能依赖任何东西，因此即使将全部资源送回也是毫无意义的。
您知道 Eclipse GAE 开发服务器是否也是如此？在持久化实体（使用其生成的 ID 立即更新）和能够通过所述 ID 成功检索它之间似乎存在明显的延迟。编辑 - 查询是“SELECT m FROM Message m WHERE Id = ”
您无法根据开发服务器衡量一致性/性能。您只能就生产环境的行为方式发表声明。开发服务器尝试（尽可能）模拟生产环境，但它根本不是生产环境。
我相信您，如果您不能信任主要行为，那么将对象的副本发回可能会更糟。情况，因为它可以隐藏实际发生的事情，如果发生中断。

【解决方案2】：

这取决于您使用的 JSON REST 协议。总是返回一个 json 对象不是很 RESTful。

你应该看看其中的一些：

回答你的问题：我更喜欢使用资源本身知道它的 URL 的格式，所以我会使用 201 但也返回整个资源。

最简单的方法是使用带有方便 url 架构的 jsonapi，因此您可以通过 url 找到资源，因为您知道 id。

【讨论】：

感谢您的回答。您能否详细说明这如何帮助解决最终一致性问题？如果客户端请求响应中提供的 URI，它们仍然可能会遇到不一致的节点。另外，我的问题从未提到过 JSON :)
如果您在响应中提供整个对象，客户端不必再次获取资源，因此应该有足够的时间来同步您的节点。此外，如果由于某些原因同步需要很长时间，您可以提供当前节点的 url。