小编Jul*_*hke的帖子

首先,一些定义:

PUT在第9.6节RFC 2616中定义:

PUT方法请求将所包含的实体存储在提供的Request-URI下.如果Request-URI引用已经存在的资源,则封闭的实体应该被视为驻留在源服务器上的实体的修改版本.如果Request-URI未指向现有资源,并且该URI能够被请求用户代理定义为新资源,则源服务器可以使用该URI创建资源.

PATCH在RFC 5789中定义:

PATCH方法请求将请求实体中描述的一组更改应用于Request-URI标识的资源.

另外根据RFC 2616第9.1.2节, PUT是幂等的,而PATCH则不是.

现在让我们来看一个真实的例子.当我/users使用数据进行POST {username: 'skwee357', email: 'skwee357@domain.com'}并且服务器能够创建资源时,它将响应201和资源位置(假设/users/1),并且/users/1将返回对GET的任何下一次调用{id: 1, username: 'skwee357', email: 'skwee357@domain.com'}.

现在假设我要修改我的电子邮件.电子邮件修改被视为"一组更改",因此我应该修补/users/1 " 补丁文档 ".在我的情况下,它将是一个json {email: 'skwee357@newdomain.com'}.然后服务器返回200(假设权限正常).这让我想到第一个问题:

• PATCH不是幂等的.它在RFC 2616和RFC 5789中也这么说.但是如果我发出相同的PATCH请求(使用我的新电子邮件),我将获得相同的资源状态(将我的电子邮件修改为所请求的值).为什么PATCH不是幂等的？

PATCH是一个相对较新的动词(2010年3月引入的RFC),它解决了"修补"或修改一组字段的问题.在引入PATCH之前,每个人都使用PUT来更新资源.但是在引入PATCH之后,让我感到困惑的是当时使用的PUT是什么？这让我想到了第二个(也是主要的)问题:

• 什么是PUT和PATCH之间的真正区别？我读过PUT可能用于替换特定资源下的整个实体,因此应该发送完整实体(而不是像PATCH一样发送属性集).这种情况的实际用法是什么？您希望何时替换/覆盖特定资源URI下的实体以及为什么不将此类操作视为更新/修补实体？我在PUT中看到的唯一实际用例是在集合上发布PUT,即/users替换整个集合.在引入PATCH之后,在特定实体上发布PUT是没有意义的.我错了吗？

我有一个关于网址的问题:

我已经阅读了RFC 3986,但仍然有一个关于一个URL的问题:

如果URI包含权限组件,则路径组件
必须为空或以斜杠("/")字符开头.如果URI不包含权限组件,则路径不能
以两个斜杠字符("//")开头.此外,URI引用
(第4.1节)可以是相对路径引用,在这种情况下,
第一个路径段不能包含冒号(":")字符.ABNF
需要五个单独的规则来消除这些情况的歧义,其中只有一个与给定URI引用中的路径子字符串匹配.我们使用通用术语"路径组件"来描述
解析器与其中一个规则匹配的URI子字符串.

我知道,这//server.com:80/path/info是有效的(它是一个架构相对URL)

我也知道这http://server.com:80/path//info是有效的.

但我不确定以下一个是否有效:

http://server.com:80//path/info

我的问题背后的问题是,http://server.com:80//path/info当URI http://server.com:80/path/info由限制创建时,不会发送cookie/path

在我正在使用的环境(Tomcat 6)中,路径段中的百分比序列显然在映射到@PathVariable时使用ISO-8859-1进行解码.

我希望它是UTF-8.

我已经将Tomcat配置为使用UTF-8(使用server.xml中的URIEncoding属性).

Spring/Rest是自己进行解码吗？如果是,我可以在哪里覆盖默认编码？

附加信息; 这是我的测试代码:

@RequestMapping( value = "/enc/{foo}", method = RequestMethod.GET )
public HttpEntity<String> enc( @PathVariable( "foo" ) String foo, HttpServletRequest req )
{
  String resp;

  resp = "      path variable foo: " + foo + "\n" + 
         "      req.getPathInfo(): " + req.getPathInfo() + "\n" +
         "req.getPathTranslated(): " + req.getPathTranslated() + "\n" + 
         "    req.getRequestURI(): " + req.getRequestURI() + "\n" + 
         "   req.getContextPath(): " + req.getContextPath() + "\n";

  HttpHeaders headers = new HttpHeaders();
  headers.setContentType( new MediaType( "text", …

我真正不懂的是使用'？'的好处 而不是网址中的"&":

如果我们使用不同的字符作为第一个分隔符,它会使任何人的生活更轻松.你能想出一个合理的解释吗？

编辑:经过更多的研究,我发现"&"可以是文件名(terms&conditions.html)的一部分,所以"？" 是一个很好的分离器.但我还是觉得用"？" for separators使生活更轻松(从url生成器和解析器的角度来看):

使用"&"是否有任何优势,乍看之下并不清楚？

这可能是一个自我回答的问题,但是我希望你们中的一个人能够指出我声明或者可以推断的任何资源,在HTTP或REST中声明HTTP方法名称时是使用大写或小写字母要求.我看到的大多数示例都以大写字母表示GET,PUT,POST,DELETE,PATCH等,而我假设HTTP方法字段名称不区分大小写 - 例如,"get"同样有效作为"GET".传统上我总是使用大写字母,但我想确定.

在W3C明确声明该方法是区分大小写的,并使用大写字母,但在我的辛苦,我经常遇到用较低的情况下,我认为是不正确的HTTP方法字段值,所以从我的POV,似乎做法,标准在这个问题上有点脱节.

大写是正确的 - 对吗？

如果帖子使用“multipart/form-data”内容类型，并且每个部分可以是文件或其他内容类型。

如果我想使用 GZIP，GZIP 是否应该应用于所有部分的整个帖子正文，或者是否可以选择某些文件使用 gzip 内容编码，而某些文件则不使用。

有没有标准或者只是惯例？

谢谢

例如，我可以在“file1”部分下面添加 Content-Encoding:gzip

Host: localhost:8081
Connection: keep-alive
Content-Length: 317
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36
Cache-Control: no-cache
Origin: chrome-extension://fhbjgbiflinjbdggehcddcbncdddomop
Postman-Token: 7143164d-0da5-0e1d-112e-91f2a21c22c2
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryPZAv0gGlJrA4ABu2
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9,zh-CN;q=0.8,zh;q=0.7

------WebKitFormBoundaryPZAv0gGlJrA4ABu2
Content-Disposition: form-data; name="key1"

value1
------WebKitFormBoundaryPZAv0gGlJrA4ABu2
Content-Disposition: form-data; name="file1"; filename="sample_file.txt"
Content-Type: text/plain
Content-Encoding: gzip ---------------------------IS IT OK TO ADD GZIP HERE?

This is a sample file content!
------WebKitFormBoundaryPZAv0gGlJrA4ABu2--

根据这个:http://www.w3.org/TR/html4/present/styles.html#h-14.6 我可以直接在http标头中链接样式表.在PHP中它看起来像这样:

header('Link: <http://www.acme.com/corporate.css>; REL=stylesheet');

这样做有什么缺点吗？

如果端点'/ tokens/verify'的令牌错误,我返回状态码401,并且不需要向用户发送任何正文内容.

为application/json内容类型发送空体是否正确？

当我在某个 URL 上向用户询问 HTTP 基本身份验证时，浏览器Authorization仅发送此 URL 和其他一些 URL 的标头。

用 PHP 编写的测试用例脚本：http : //testauth.veadev.tk/

有三个 URL 可以要求提供凭据（您可以使用任何随机值）。注销链接（在浏览器身份验证表单中按“取消”按钮后删除当前凭据，不适用于 IE）。链接到根 URL 和一些测试更深的 URL。

问题：

1. 为什么浏览器不在URL发送Authorization标头，/如果HTTP/1.0 401 Unauthorized是在 发送的/system/dev？ 重复：打开干净的http://testauth.veadev.tk/，单击Auth2，输入任何凭据，之后您将被转发到/。您会看到Auth: null这意味着浏览器没有发送凭据标头。

2. 为什么浏览器Authorization在/ifHTTP/1.0 401 Unauthorized发送时发送 标头/dev？ 重复：打开干净的http://testauth.veadev.tk/，单击Auth1，输入任何凭据，之后您将被转发到/。您会看到类似的内容Auth: string 'Basic dHQ6dHQ=' (length=14)，这意味着凭据标头是由浏览器发送的。

3. 如果您重复第一个案例，然后单击Auth1您将在Root所有其他页面上获得凭据。为什么？

4. 如果您单击Auth3( …