通过HTTP PATCH请求包含数据的正确方法 [英] Proper way to include data with an HTTP PATCH request

问题描述

当我将HTTP PATCH请求放在一起时，在URL参数之外包括数据的选择是什么?

When I'm putting together an HTTP PATCH request, what are my options to include data outside of URL parameters?

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

Will any of the following work, and what's the most common choice?

• multipart/form-data
• application/x-www-form-urlencoded
• 原始JSON
• ...还有其他人吗?

推荐答案

对于PATCH请求的实体没有任何限制/rfc5789"rel =" noreferrer> RFC 5789 .因此，从理论上讲，您在这方面的选择是无限的.

There are no restrictions on the entity bodies of HTTP PATCH requests as defined in RFC 5789. So in theory, your options in this area are unlimited.

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

In my opinion the only sensible choice is to use the same Content-Type used to originally create the resource. The most common choice is application/json simply because most modern APIs utilize JSON as their preferred data transfer format.

RFC 5789中关于PATCH实体主体应该和不应该包括的部分的唯一相关事件声明在Content-Type方面保持沉默:

The only relevent statement RFC 5789 makes in regard to what should and shouldn't be part of your PATCH entity body is silent on the matter of Content-Type:

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

the enclosed entity contains a set of instructions describing how a resource currently residing on the origin server should be modified to produce a new version.

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

In summary, how you choose to modify resources in your application is entirely up to you.

这篇关于通过HTTP PATCH请求包含数据的正确方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！