当我整理HTTP PATCH请求时，我可以选择在URL参数之外包含数据吗？
以下任何一项工作，以及最常见的选择是什么？
答案 0 :(得分：4)
RFC 5789中定义的HTTP PATCH请求的实体主体没有任何限制。所以从理论上讲，你在这方面的选择是无限的。
在我看来，唯一明智的选择是使用与最初创建资源相同的Content-Type。最常见的选择是application/json，因为大多数现代API都使用JSON作为首选数据传输格式。
关于应该和不应该成为PATCH实体机构一部分的唯一相关性声明RFC 5789对Content-Type的问题保持沉默：
随附的实体包含一组说明，描述如何修改当前驻留在原始服务器上的资源以生成新版本。
总之，您选择如何修改应用程序中的资源完全取决于您。
答案 1 :(得分：3)
正如 rdlowrey 所写，RFC 5789并未强制要求特定的内容类型，因此格式的选择取决于您。
但是，使用您列出的一般格式或构成您自己的格式是不可互操作的，开发人员可能很难弄清楚您选择的语义。 RFC An official erratum以更正式的方式说明了这一点：
将
PATCH请求应用于资源状态的方法是 由请求的媒体类型确定。如果服务器收到PATCH请求使用其规范未定义的媒体类型 特定于PATCH的语义，服务器应该拒绝请求 返回415 Unsupported Media Type状态代码，除非更多 特定错误状态代码优先。特别是，服务器不应该假定通用的
PATCH语义 没有定义它们的媒体类型，例如application/xml或application/json。这样做会导致互操作性问题， 因为PATCH的语义变得特定于该资源， 而非一般。
（引用格式为可读性，但未更改）
其规范定义PATCH语义的一种媒体类型是application/json-patch+json，也称为 JSON补丁：RFC 6902。我认为在处理最初发布为JSON的数据时，它可以被视为“标准”选择（至少）。
答案 2 :(得分：0)
PATCH方法在RFC 5789中定义。但是，此文档未对有效负载强制使用任何媒体类型：
PATCH方法请求将请求实体中描述的一组更改应用于Request-URI所标识的资源。一组变更以一种称为“补丁文件”的格式表示，该格式由媒体类型标识。
几年后发布的其他RFC定义了一些媒体类型，用于描述对资源应用的一组更改，适用于PATCH ing：
application/json-patch+json 在RFC 6902中定义：
JSON修补程序定义了JSON文档结构，用于表示要应用于JavaScript对象表示法（JSON）文档的一系列操作；它适合与HTTP
PATCH方法一起使用。application/json-patch+json媒体类型用于标识此类补丁文档。
application/merge-patch+json 在RFC 7396中定义：
该规范定义了JSON合并补丁程序格式和处理规则。合并修补程序格式主要旨在与HTTP
PATCH方法一起使用，以描述对目标资源内容的一组修改。