代码之家  ›  专栏  ›  技术社区  ›  Freid001

用于附加到资源对象的HTTP动词?

  •  0
  • Freid001  · 技术社区  · 5 年前

    我正在尝试构建一个符合 json:api 规格。

    我的api有三个资源 /task , /item /result .任务有字段 name , description state 。一个项目有字段 itemName A. count 为该项目和 计数 当用户使用 GET 请求。这个 计数 当项目更新时,在服务器端递增。任务和项目之间存在一对多的关系。从某种意义上说,项目是附加到任务上的。当任务状态发生变化时,一个脚本会在服务器端运行,对相关项目进行一些处理。脚本完成后,输出将在结果资源中可用。

    根据规范,我正在使用 POST 创建任务的动词和 PATCH 更新任务。我只想要一个端点来处理项目的创建/更新(追加)。但是,我不确定该用哪个动词?我能用吗 补丁 更新项目,但如果项目不存在,还要创建项目?

    我还想也许我应该使用 PUT 动词。但是,我在这里的理解是,这个动词只是用来替换资源,而不是更新它。我认为这不适合我的用户情况,因为更新时项目计数会增加,所以替换它不是我想做的。但是,计数是在服务器端处理的,因此用户无论如何都不能选择“替换”计数。

    0 回复  |  直到 5 年前
        1
  •  1
  •   Community Mohan Dere    4 年前

    我在这里的理解是,这个动词只是用来替换资源,而不是更新它。

    这是一个普遍的理解——错误,但很常见。

    IANA注册表记录了以下语义的权威参考 http methods 。大多数常见的定义如下 RFC 7231 ; PATCH的定义如下 RFC 5789 .

    PUT 当消息正文是您希望资源的完整表示时,这是一个合适的选择。考虑“保存文件”可能更容易;PUT描述了客户端希望文档保存后的样子。

    使用PUT更新文档或创建文档都是合适的,前提是客户端知道文档的标识符(就像我们可以使用save创建文件或替换文件一样,但我们需要知道文件名)。

    如果你阅读了规范的文本,你会看到——虽然请求的语义是“按原样”保存新的表示形式,但服务器并不需要这样做——毕竟,服务器控制着自己的文档——所以有空间覆盖只读字段,或者只应由服务器更新的字段。您需要对响应头有点小心,以避免暗示您按原样保存了表示,但除此之外,您应该没问题。