【前端 · 面试 】HTTP 总结(三)—— HTTP 请求方法

·  阅读 1106
【前端 · 面试 】HTTP 总结(三)——  HTTP 请求方法

这是我参与8月更文挑战的第3天,活动详情查看:8月更文挑战

最近我在做前端面试题总结系列,感兴趣的朋友可以添加关注,欢迎指正、交流。

争取每个知识点能够多总结一些,至少要做到在面试时,针对每个知识点都可以侃起来,不至于哑火。

前言

在日常开发中,前端和服务端数据交互时,使用最多的大概就是 HTTP 请求了,今天我们就来总结一下所有的 HTTP 请求方法,并且了解一下后台返回的一些常见状态码的含义。

请求方法分类总结

根据 HTTP 标准,HTTP 请求可以使用多种请求方法。

HTTP1.0 定义了三种请求方法: GET, POST 和 HEAD 方法。

HTTP1.1 新增了六种请求方法:OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。

HTTP 请求方法总结

GET 方法

GET 是最常用的 HTTP 请求方法,会显示请求指定的资源,并返回响应主体,一般对它的期望是安全且幂等的。

所谓安全是指该操作用于获取信息而非修改信息。换句话说,GET 请求一般不应产生副作用。就是说,它仅仅是获取资源信息,就像数据库查询一样,不会修改和增加数据,不会影响资源的状态。

这里安全的含义仅仅是指是非修改信息。

幂等的概念简单点来说,就是指对同一个 URL 的多个请求应该返回同样的结果。

查询字符串(名称/值对)是在 GET 请求的 URL 中发送的,在 URL 后加 ? 连接查询字符串,多条查询字符串通过 & 来连接,比如:

https://cn.bing.com/search?q=%E7%BC%96%E7%A8%8B%E4%B8%89%E6%98%A7&PC=U316&FORM=CHROMN
复制代码

GET 请求的一些其他特性:

  • GET 请求可被缓存
  • GET 请求保留在浏览器历史记录中
  • GET 请求可被收藏为书签
  • GET 请求不应在处理敏感数据时使用
  • GET 请求有长度限制
  • GET 请求只应当用于取回数据(不修改)

HEAD 方法

与 GET 方法一样,都是向服务器发出指定资源的请求,只不过服务器将不传回资源的本文部分,只返回头部消息。

它的好处在于,使用这个方法可以在不必传输全部内容的情况下,就可以获取其中“关于该资源的信息”(元信息或称元数据),对资源的首部进行检查,比如:

  • 如果 GET /users 返回用户列表,
  • 那么 HEAD /users 将发出相同的请求,但不会返回用户列表。

HEAD 方法的使用场景

  • 在不获取资源的情况下,了解资源的一些信息,比如资源类型;
  • 通过查看响应中的状态码,可以确定资源是否存在;
  • 通过查看首部,测试资源是否被修改。

POST 方法

POST 方法用于向指定资源提交数据,请求服务器进行处理(例如提交表单或者上传文件),数据被包含在请求本文中。

POST 请求可能会创建新的资源或修改现有资源,或二者皆有。每次提交,表单的数据被浏览器用编码到HTTP请求的body里。

浏览器发出的POST请求的body的主要格式

  • application/x-www-form-urlencoded 用来传输简单的数据,如 "key1=value1&key2=value2" 这样的格式。
  • multipart/form-data 主要用来传输文件内容。
  • application/json 告诉服务端消息主体是序列化后的 JSON 字符串。
  • text/plain 纯文本格式

采用 multipart/form-data 是因为 application/x-www-form-urlencoded 的编码方式对于文件这种二进制的数据非常低效。

除了原生的content-type,开发人员也可以完全自定义数据提交格式!

POST 请求的其他特性:

  • POST 请求不会被缓存
  • POST 请求不会保留在浏览器历史记录中
  • POST 不能被收藏为书签
  • POST 请求对数据长度没有要求

PUT 方法

PUT 方法用于将数据发送到服务器来创建/更新资源。

PUT 与 POST 方法的区别在于,PUT 方法是幂等的:调用一次与连续调用多次是等价的(即没有副作用),而连续调用多次 POST 方法可能会有副作用,比如将一个订单重复提交多次。

PUT 方法可能的响应

  • 如果目标资源不存在,并且PUT方法成功创建了一份,那么源头服务器必须返回 201(Created) 来通知客户端资源已创建。
  • 如果目标资源已经存在,并且依照请求中封装的表现形式成功进行了更新,那么,源头服务器必须返回 200 (OK) 或者 204 (No Content) 来表示请求的成功完成。

DELETE 方法

DELETE 方法就是请求服务器删除指定 URL 所对应的资源。但是,客户端无法保证删除操作一定会被执行,因为 HTTP 规范允许服务器在不通知客户端的情况下撤销请求。

DELETE 方法可能的响应码

如果 DELETE 方法成功执行,那么可能会有以下几种状态码:

  • 状态码 202 (Accepted) 表示请求的操作可能会成功执行,但是尚未开始执行。
  • 状态码 204 (No Content) 表示操作已执行,但是无进一步的相关信息。
  • 状态码 200 (OK) 表示操作已执行,并且响应中提供了相关状态的描述信息。

TRACE 方法

TRACE 方法实现沿通向目标资源的路径的消息“回环”(loop-back)测试 ,提供了一种实用的 debug 机制。

请求的最终接收者应当原样反射(reflect)它接收到的消息,作为一个 Content-Type 为 message/http 的200(OK)响应的消息的主体(body)返回给客户端 。

最终接收者是指初始(origin)服务器,或者第一个接收到 Max-Forwards 值为 0的请求的服务器。

我们都知道,客户端在发起一个请求时,这个请求可能要穿过防火墙、代理、网关、或者其它的一些应用程序。这中间的每个节点都可能会修改原始的 HTTP 请求。由于有一个“回环”诊断,在请求最终到达服务器时,服务器会弹回一条 TRACE 响应,并在响应主体中携带它收到的原始请求报文的最终模样。这样客户端就可以查看 HTTP 请求报文在发送的途中,是否被修改过了。

PATCH 方法

在HTTP协议中,请求方法 PATCH 用于对资源进行部分修改。

在HTTP协议中, PUT 方法已经被用来表示对资源进行整体覆盖, 而 POST 方法则没有对标准的补丁格式的提供支持。不同于 PUT 方法,而与 POST 方法类似,PATCH 方法是非幂等的,这就意味着连续多个的相同请求会产生不同的效果。

要判断一台服务器是否支持 PATCH 方法,那么就看它是否将其添加到了响应首部 Allow 或者 Access-Control-Allow-Methods (在跨域访问的场合,CORS)的方法列表中 。

另外一个支持 PATCH 方法的隐含迹象是 Accept-Patch 首部的出现,这个首部明确了服务器端可以接受的补丁文件的格式。

响应

204 状态码表示这是一个操作成功的响应,因为响应中不带有消息主体。

OPTIONS 方法

OPTIONS 方法用于获取目的资源所支持的通信选项。

客户端可以对特定的 URL 使用 OPTIONS 方法,也可以对整站(通过将 URL 设置为“*”)使用该方法。

若请求成功,则它会在 HTTP 头中包含一个名为 “Allow” 的头,值是所支持的方法,如 “GET, POST”。

使用示例

可以使用 OPTIONS 方法对服务器发起请求,以检测服务器支持哪些 HTTP 方法,响应报文包含一个 Allow 首部字段,该字段的值表明了服务器支持的所有 HTTP 方法:

HTTP/1.1 200 OK
Allow: OPTIONS, GET, HEAD, POST
Cache-Control: max-age=604800
Date: Thu, 13 Oct 2016 11:45:00 GMT
Expires: Thu, 20 Oct 2016 11:45:00 GMT
Server: EOS (lax004/2813)
x-ec-custom-error: 1
Content-Length: 0
复制代码

CONNECT 方法

CONNECT 方法可以开启一个客户端与所请求资源之间的双向沟通的通道。它可以用来创建隧道(tunnel)。

总结

以上就是 HTTP 方法的内容总结,根据场景合理使用各个方法,可以起到优化性能、增加网络安全的效果。

~

~ 本文完,感谢阅读!

~

学习有趣的知识,结识有趣的朋友,塑造有趣的灵魂!

大家好,我是〖编程三昧〗的作者 隐逸王,我的公众号是『编程三昧』,欢迎关注,希望大家多多指教!

你来,怀揣期望,我有墨香相迎! 你归,无论得失,唯以余韵相赠!

知识与技能并重,内力和外功兼修,理论和实践两手都要抓、两手都要硬!

分类:
前端
标签: