8wDlpd.png
首页
8wDFp9.png
分类
8wDEOx.png
8wDMfH.png
消息
8wDKte.png
我的
  2. http
  3. 使用 HTTP PATCH 请求包含数据的正确方法

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

alexmherrmann 2月前
45 0

当我整理 HTTP PATCH 请求时，我有哪些选项可以包含 URL 参数之外的数据？以下任何一种方法都可以吗？最常见的选择是什么？multipart/form-d...

当我整理 HTTP PATCH 请求时，我可以通过哪些选项来包含 URL 参数之外的数据？

以下任何一种方法都有效吗？最常见的选择是什么？

  • 多部分/表单数据
  • 应用程序/x-www-form-urlencoded
  • 原始 JSON
  • ...还有其他的吗？
帖子版权声明 1、本帖标题：使用 HTTP PATCH 请求包含数据的正确方法
    本站网址：http://xjnalaquan.com/
2、本网站的资源部分来源于网络，如有侵权，请联系站长进行删除处理。
3、会员发帖仅代表会员个人观点，并不代表本站赞同其观点和对其真实性负责。
4、本站一律禁止以任何方式发布或转载任何违法的相关信息，访客发现请向站长举报
5、站长邮箱：yeweds@126.com 除非注明，本帖由alexmherrmann在本站《http》版块原创发布， 转载请注明出处！
收藏的用户（0） X
正在加载信息~
最新回复 (0)
  • 引用 2楼

    HTTP 请求的实体主体没有任何限制 PATCH 中对 RFC 5789 。因此，理论上，您在这方面的选择是无限的。

    我认为唯一明智的选择是使用 Content-Type 最初创建资源时所用的格式。最常见的选择 application/json 只是因为大多数现代 API 都使用 JSON 作为其首选的数据传输格式。

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

    封闭的实体包含一组指令，描述如何修改当前驻留在原始服务器上的资源以生成新版本。

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

  • 引用 3楼

    不。媒体类型应该描述补丁格式。如果您使用的媒体类型缺少在 PATCH 中使用的定义，则说明您没有按照应有的方式使用 PATCH。

  • 引用 4楼

    @JulianReschke 可以随意做一些有成效的事情，并发布 RFC 参考资料来供大家参考。否则你对任何人都没有帮助。特别是，如果这个答案是错误的，你应该发布一个正确的答案。

  • 引用 5楼

    补丁很奇怪。他们发布的 rfc 明确指出没有任何标准媒体类型，假设人们会读懂字里行间的意思并创建自己的媒体类型。两年后，Mark Nottingham 添加了勘误表，因为人们没有创建特定于补丁的媒体类型，大喊“互操作性！”，一年后，json 补丁 rfc 发布了。如果互操作性如此令人担忧，那么他们难道不应该在发布补丁 rfc 的同时发布至少一种特定于补丁的媒体类型吗？

  • JWT 2月前 0 只看Ta
    引用 6楼

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

    但是，使用您列出的通用格式或自行编写格式无法实现互操作，开发人员可能很难理解您选择的语义。RFC 官方勘误表 以更正式的方式说明了这一点：

    方法 PATCH 由请求的媒体类型决定。如果服务器收到的请求 PATCH 的媒体类型的规范未定义特定于的语义 PATCH ，则服务器应通过返回 415 Unsupported Media Type 状态代码来拒绝该请求，除非更具体的错误状态代码优先。

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

    （为方便阅读，引用格式已更改，其他内容保持不变）

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

  • 引用 7楼

    该 PATCH 中定义 RFC 5789 。但是，本文档不强制要求有效负载使用任何媒体类型：

    该 PATCH 方法请求将请求实体中描述的一组更改应用于 所标识的资源 Request-URI 。更改集以媒体类型标识的“补丁文档”格式表示。

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

    application/json-patch+json

    中定义 RFC 6902 :

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

    application/merge-patch+json

    中定义 RFC 7396 :

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

  • 引用 8楼

    Json Patch 和 Merge Patch 的问题在于，它们都要求原始资源自上次被客户端获取以来没有被修改过，否则对数组元素的操作可能会对错误的元素执行。因此，如果您认为 PATCH（很大程度上）解决了并发更新的问题，那您就错了 - 您仍然需要 ETag/If-Match 之类的机制。

返回
作者最近主题：