具有版本号的记录的 RESTful API 的最佳实践。我使用 PUT 吗？
Best practices for RESTful API for records with version numbers. Do I use PUT?
需要一些有关在 node.js
中构建 RESTful API 的最佳实践的指导
假设我有这样一个人的记录：
{
id: 1,
name: 'Jon',
age: 25,
recordVersion: 1
}
如果我需要在每次更改值时增加 recordVersion，我是否仍会使用 HTTP PUT 来更新此记录？我已经研究过 PUT 应该如何幂等并且应该包含原始资源的新更新表示，所以我不确定该怎么做。
我可以在第一次 PUT 调用时增加 recordVersion 属性 并在第二次 PUT 调用时发送一个错误，其中相同的 versionNumber 为 1（因为那时它会增加到 2），但是确实如此这遵循 RESTful API 标准？
表示!=状态
通过网络发送的资源是状态的表示，而不是实际状态。
删除 recordVersion 并在幕后对其进行更新是完全没问题的 - 但是，如果您这样做，最好也将其从通过 GET 对该资源的表示 return 中删除.要理解为什么：幂等性是关于如果连续多次应用该操作会发生什么（如果其他操作发生在两者之间......则不能保证），以及关于 observable 副作用。
- PUT没有版本的数据
- 数据已更新
- 版本代码递增
- 如果您执行 GET，您将获得 PUT 中的数据（无版本）
- 在没有版本的情况下再次输入相同的数据
- 数据已更新
- 版本代码递增
- 如果您执行 GET，您将获得与 PUT 相同的数据（无版本）
幂等性，因为资源表示没有因为调用 PUT 两次而改变，即使内部实体状态已经改变 - 没有 observable 副作用。
有关详细信息，请参阅 http://restcookbook.com/HTTP%20Methods/idempotency/。
使用版本代码检测冲突
如您所见，您可以使用检查版本并在版本发生更改时抛出错误 - 事实上，这非常 RESTful，在我看来，这是处理 PUT 的最佳方式，因为它有助于避免（通常是莫名其妙的）并发错误。如果您检测到这种情况，则 return 一个 409 Conflict http 状态代码是合适的。
这是如何工作的：
- 将数据放入版本 (v1)
- 数据已更新
- 版本代码递增
- 如果您执行 GET，您将获得使用 新 版本 (v2) 的 PUT 数据（这是 副作用，但是第一次做手术时产生副作用是可以的。
- 使用版本 (v1) 再次放入相同的数据
- 检测到冲突，因为
v1 != v2
- 409 冲突 returned
- 如果您执行 GET，您将获得与第一次操作相同的结果 - 您最初使用版本 v2
PUT 的数据
这是幂等的，因为调用该操作两次没有可观察到的副作用。
客户端应该响应 409，执行另一个 GET 以获取最新版本代码，并可能向用户提供将他们的更改与同时更改的任何其他内容合并的机会。
人们常常将幂等性与认为对操作的响应必须与多次调用的结果相同的想法混淆，但事实并非如此 - 它是关于没有由于多次顺序调用而产生的可观察到的副作用来电。
需要一些有关在 node.js
中构建 RESTful API 的最佳实践的指导假设我有这样一个人的记录：
{
id: 1,
name: 'Jon',
age: 25,
recordVersion: 1
}
如果我需要在每次更改值时增加 recordVersion，我是否仍会使用 HTTP PUT 来更新此记录？我已经研究过 PUT 应该如何幂等并且应该包含原始资源的新更新表示，所以我不确定该怎么做。
我可以在第一次 PUT 调用时增加 recordVersion 属性 并在第二次 PUT 调用时发送一个错误，其中相同的 versionNumber 为 1（因为那时它会增加到 2），但是确实如此这遵循 RESTful API 标准？
表示!=状态
通过网络发送的资源是状态的表示，而不是实际状态。
删除 recordVersion 并在幕后对其进行更新是完全没问题的 - 但是，如果您这样做，最好也将其从通过 GET 对该资源的表示 return 中删除.要理解为什么：幂等性是关于如果连续多次应用该操作会发生什么（如果其他操作发生在两者之间......则不能保证），以及关于 observable 副作用。
- PUT没有版本的数据
- 数据已更新
- 版本代码递增
- 如果您执行 GET，您将获得 PUT 中的数据（无版本）
- 在没有版本的情况下再次输入相同的数据
- 数据已更新
- 版本代码递增
- 如果您执行 GET，您将获得与 PUT 相同的数据（无版本）
幂等性，因为资源表示没有因为调用 PUT 两次而改变，即使内部实体状态已经改变 - 没有 observable 副作用。
有关详细信息，请参阅 http://restcookbook.com/HTTP%20Methods/idempotency/。
使用版本代码检测冲突
如您所见，您可以使用检查版本并在版本发生更改时抛出错误 - 事实上，这非常 RESTful，在我看来，这是处理 PUT 的最佳方式，因为它有助于避免（通常是莫名其妙的）并发错误。如果您检测到这种情况，则 return 一个 409 Conflict http 状态代码是合适的。
这是如何工作的：
- 将数据放入版本 (v1)
- 数据已更新
- 版本代码递增
- 如果您执行 GET，您将获得使用 新 版本 (v2) 的 PUT 数据（这是 副作用，但是第一次做手术时产生副作用是可以的。
- 使用版本 (v1) 再次放入相同的数据
- 检测到冲突，因为
v1 != v2 - 409 冲突 returned
- 如果您执行 GET，您将获得与第一次操作相同的结果 - 您最初使用版本 v2 PUT 的数据
- 检测到冲突，因为
这是幂等的，因为调用该操作两次没有可观察到的副作用。
客户端应该响应 409，执行另一个 GET 以获取最新版本代码，并可能向用户提供将他们的更改与同时更改的任何其他内容合并的机会。
人们常常将幂等性与认为对操作的响应必须与多次调用的结果相同的想法混淆，但事实并非如此 - 它是关于没有由于多次顺序调用而产生的可观察到的副作用来电。