http - 使用 HTTP PATCH 请求包含数据的正确方法

Question

当我将 HTTP PATCH 请求放在一起时，我有哪些选项可以在 URL 参数之外包含数据？

以下任何一项工作，最常见的选择是什么？

score 8 · Accepted Answer

对RFC 5789PATCH中定义的 HTTP 请求的实体主体没有任何限制。所以理论上，你在这方面的选择是无限的。

在我看来，唯一明智的选择是使用Content-Type最初创建资源的相同资源。最常见的选择application/json仅仅是因为大多数现代 API 使用 JSON 作为其首选的数据传输格式。

RFC 5789 关于什么应该和不应该成为您的PATCH实体主体的唯一相关声明对以下问题保持沉默Content-Type：

随附的实体包含一组说明，描述如何修改当前驻留在源服务器上的资源以生成新版本。

总之，您选择如何修改应用程序中的资源完全取决于您。

score 4 · Accepted Answer

正如rdlowrey所写，RFC 5789不强制要求特定的内容类型，因此格式的选择取决于您。

但是，使用您列出的通用格式或创建自己的格式是不可互操作的，开发人员可能很难弄清楚您选择的语义。RFC的官方勘误表以更正式的方式说明了这一点：

将PATCH请求应用于资源状态的方式由请求的媒体类型决定。如果服务器接收到PATCH 一个媒体类型的请求，其规范没有定义特定于PATCH的语义，服务器应该通过返回状态码来拒绝该请求415 Unsupported Media Type，除非更具体的错误状态码优先。

特别是，服务器不应该PATCH为没有定义它们的通用媒体类型假设语义，例如application/xmlor application/json。这样做会导致互操作性问题，因为语义PATCH变得特定于该资源，而不是通用的。

^{（报价格式为可读性，但其他方面不变）}

一种媒体类型，其规范定义了 PATCH 语义application/json-patch+json，也称为JSON Patch：RFC 6902。我想在处理最初发布为 JSON 的数据时，它可以被认为是“标准”选择（至少）。

score 1 · Accepted Answer

该PATCH方法在RFC 5789中定义。但是，本文档不强制负载的任何媒体类型：

该PATCH方法请求将请求实体中描述的一组更改应用于由Request-URI. 这组更改以一种称为“补丁文档”的格式表示，该格式由媒体类型标识。

多年后发布的其他 RFC 定义了一些媒体类型，用于描述对应用于资源的一组更改，适用于PATCH：

`application/json-patch+json`

在RFC 6902中定义：

JSON Patch 定义了一个 JSON 文档结构，用于表达一系列操作以应用于 JavaScript Object Notation (JSON) 文档；它适合与 HTTPPATCH方法一起使用。application/json-patch+json媒体类型用于识别此类补丁文档。

在RFC 7396中定义：

本规范定义了 JSON 合并补丁格式和处理规则。合并补丁格式主要用于与 HTTPPATCH方法一起使用，作为描述对目标资源内容的一组修改的一种方式。