时间戳

首页 > 解决方案 > Rest api 强制更新资源

rest - Rest api 强制更新资源

问题描述

休息 api 允许强制更新的好习惯是什么。如果超出某些内容，正常更新将返回警告。

我刚在想：

  1. PUT /myresource/{id}?options=FORCE
  2. PUT /myresource/{id}，在有效负载中包含可选选项字段。

有更好的方法吗？

谢谢

标签： rest

解决方案

PUT /myresource/{id}?options=FORCE

这是一个坏主意，如果你坚持的话，你可能会成功。

REST 的核心思想是我们有一个统一的接口——所有资源都以相同的方式理解消息。在 PUT 的情况下，这意味着我们都理解RFC 7231中描述的消息

请求的 target-uri 指示给定消息适用于哪个资源。所以从通用组件的角度来看，PUT /myresource/{id}?options=FORCE意味着“请更新 /myresource/{id}?options=FORCE 的表示”。

请注意故意包含查询部分，它是主要资源标识的一部分。

“/myresource/{id}?options=FORCE”是与“/myresource/{id}”不同的资源标识符，即使 URI 的分层部分相同。

因此，从通用组件（如浏览器或缓存 Web 代理）的角度来看，您提出的请求将“/myresource/{id}”的缓存表示保持不变。

你可能可以让它工作：如果你仔细阅读缓存失效规范，你会发现 target-uri 不是唯一一个因对不安全请求的成功响应而失效的 URI；缓存还有望使 Location 和 Content-Location 标头标识的资源无效。

所以像这样的回应：

200 OK
Content-Location: /myresource/{id}

<<updated representation of /myresource/{id}

将使 /myresource/{id}?options=FORCE 和 /myresource/{id} 都无效。

当然，以这种方式使用 Content-Location 标头会引入其他约束。

PUT /myresource/{id}，在有效负载中包含可选选项字段。

更好 - 我们正在识别真正想要修改的资源（因此缓存现在了解正在发生的事情）。由于您可能不希望用于强制更新的可选字段成为服务器表示的一部分，因此您需要在响应中做一些额外的工作以避免暗示所请求的表示已被接受。

另一种选择是考虑使用 Authentication 标头；类似于如何使用sudo rm -rf来覆盖默认策略。实际上，您的实现逻辑应检查请求的作者是否已分配给允许进行超出默认策略允许的编辑的角色。

如果您不满意您的需求与 Authentication 标头的现有语义完全一致，您可以引入一个新标头

可以定义新的标头字段，以便当接收者理解它们时，它们可能会覆盖或增强对先前定义的标头字段的解释，定义请求评估的先决条件，或细化响应的含义。

例如，请参阅RFC 8594。

这里的困难部分是采用。

在您同时控制客户端和服务器的情况下，采用会容易得多，因为您可以强制解决问题。

推荐阅读