Skip to content

Latest commit

 

History

History
142 lines (109 loc) · 10.6 KB

09-http-methods.md

File metadata and controls

142 lines (109 loc) · 10.6 KB
Raw

HTTP 请求方法

CONNECT方法可以开启一个客户端与所请求资源之间的双向沟通的通道。它可以用来创建隧道(tunnel)。成功的响应有主体(body)，其他否。

  • 只有当浏览器配置为使用代理服务器时才会用到 CONNECT 方法，一些代理服务器在创建隧道时会要求进行身份验证。
  • 例如，浏览器通过代理服务器发起 HTTPS 请求，请求的站点地址和端口号都是加密保存于 HTTPS 请求头中的，代理服务器是如何既确保通信是加密的（代理服务器自身也无法读取通信内容）又知道该往哪里发送请求呢:
    • 浏览器需要先通过明文 HTTP 形式向代理服务器发送一个 CONNECT 请求告诉它目标站点地址及端口号。
    • 当代理服务器收到这个请求后，会在对应的端口上与目标站点建立一个 TCP 连接，
      • 连接建立成功后返回一个 HTTP 200 状态码告诉浏览器与该站点的加密通道已建成。
    • 接下来代理服务器仅仅是来回传输浏览器与该服务器之间的加密数据包，代理服务器并不需要解析这些内容以保证 HTTPS 的安全性。

DELETE方法用于删除指定的资源。请求可能有主体、成功的返回可以有主体、是幂等

  • 如果 DELETE 方法成功执行，那么可能会有以下几种状态码：
    • 状态码 202 (Accepted) 表示请求的操作可能会成功执行，但是尚未开始执行。
    • 状态码 204 (No Content) 表示操作已执行，但是无进一步的相关信息。
    • 状态码 200 (OK) 表示操作已执行，并且响应中提供了相关状态的描述信息。

GET方法请求指定的资源。使用 GET 的请求应该只用于获取数据。成功的响应有主体、安全、是幂等、可缓存、支持 HTML 表单中使用

  • 在 GET 请求中发送 body/payload 可能会导致一些现有的实现拒绝该请求。虽然规范中没有禁止，但语义没有定义，最好是避免。

HEAD方法请求资源的头部信息，并且这些头部与 HTTP GET 方法请求时返回的一致。安全、是幂等、可缓存

  • 如果 HEAD 请求有响应主体，会被忽略。
  • HEAD 方法可以看做是 GET 方法的一个“简化版”或者“轻量版”。因为它的响应头与 GET 完全相同。
  • 使用场景: 检测资源是否存在；在下载一个大文件前先获取其大小再决定是否要下载，以此可以节约带宽资源。

OPTIONS方法用于获取目的资源所支持的通信选项。成功的响应有主体、安全、是幂等

  • 客户端可以对特定的 URL 使用 OPTIONS 方法，也可以对整站（通过将 URL 设置为“*”）使用该方法。
  • 可以使用 OPTIONS 方法对服务器发起请求，以检测服务器支持哪些 HTTP 方法。
  • 在 CORS 中，可以使用 OPTIONS 方法发起一个预检请求，以检测实际请求是否可以被服务器所接受。

PUT方法使用请求中的负载创建或者替换目标资源。请求有主体、可能有响应主体、是幂等

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

POST方法发送数据给服务器。请求主体的类型由 Content-Type 首部指定。请求有主体、成功的响应有主体、支持 HTML 表单中使用。

  • PUT 和 POST 方法的区别是，PUT 方法是幂等的：连续调用一次或者多次的效果相同（无副作用）。
  • POST 方法不是幂等的，连续调用同一个 POST 可能会带来额外的影响，比如多次提交订单。

PATCH方法用于对资源进行部分修改。请求可以有主体、成功的响应有主体。

  • PUT 方法已经被用来表示对资源进行整体覆盖，而 POST 方法则没有对标准的补丁格式的提供支持。
  • 不同于 PUT 方法，而与 POST 方法类似，PATCH 方法是非幂等的，这就意味着连续多个的相同请求会产生不同的效果。
  • POST 请求通常通过 HTML 表单发送，并导致服务器发生变化。

TRACE 方法实现沿通向目标资源的路径的消息环回（loop-back）测试，提供了一种实用的 debug 机制。安全、是幂等，其他为否。

  • 请求的最终接收者应该将收到的消息作为 200 响应的内容返回给客户端。例如 Content-Type 为 message/http 的 200 响应。
  • 最终接收者是指源（origin）服务器，或者第一个接收到 Max-Forwards 值为 0 的请求的服务器。
  • TRACE 方法主要用于诊断，也就是说，用于验证请求是否如愿穿过了请求 / 响应链。
  • 客户端决不能在 TRACE 请求中生成包含敏感数据的字段，因为这些敏感数据可能会被响应所披露。

安全(Safe): 如果说一个 HTTP 方法是安全的，是指这是个不会修改服务器的数据的方法。

  • 也就是说，这是一个对服务器只读操作的方法。这些方法是安全的：GET，HEAD 和 OPTIONS。
  • 所有安全的方法都是幂等的，但并非所有幂等方法都是安全的，例如，PUT 和 DELETE 都是幂等的，但不是安全的。

幂等(Idempotent):一个 HTTP 方法是幂等的，指的是同样的请求被执行一次与连续执行多次的效果是一样的，服务器的状态也是一样的。

  • 在正确实现的条件下， GET ， HEAD ， PUT 和 DELETE 等方法都是幂等的

可缓存(Cacheable): 的响应是指可以缓存的 HTTP 响应，即储存起来以便以后检索和使用，省去了对服务器的新请求。

HTTP 响应状态码

HTTP 响应状态码用来表明特定 HTTP 请求是否成功完成。 响应被归为以下五大类：

  • 信息响应 (100–199) : 101
  • 成功响应 (200–299) : 200
  • 重定向消息 (300–399) : 304
  • 客户端错误响应 (400–499) : 400、401、403、404
  • 服务端错误响应 (500–599) : 500、501、502、503

常见的响应状态码

  • 100 Continue
    • 这个临时响应表明，迄今为止的所有内容都是可行的，客户端应该继续请求，如果已经完成，则忽略它。
  • 101 Switching Protocols
    • 该代码是响应客户端的 Upgrade 请求头发送的，指明服务器即将切换的协议。(例如使用 ws 时)
  • 200 OK
    • 请求成功。GET: 资源已被提取并在消息正文中传输。HEAD: 实体标头位于消息正文中。
    • PUT or POST: 描述动作结果的资源在消息体中传输。TRACE: 消息正文包含服务器收到的请求消息。
  • 201 Created
    • 该请求已成功，并因此创建了一个新的资源。这通常是在 POST 请求，或是某些 PUT 请求之后返回的响应。
  • 202 Accepted
    • 请求已经接收到，但还未响应，没有结果。表示请求的操作可能会成功执行，但是尚未开始执行。
    • 意味着不会有一个异步的响应去表明当前请求的结果，预期另外的进程和服务去处理请求，或者批处理。
  • 204 No Content
    • 对于该请求没有的内容可发送，但头部字段可能有用。用户代理可能会用此时请求头部信息来更新原来资源的头部缓存字段。
  • 300 Multiple Choice
    • 请求拥有多个可能的响应。用户代理或者用户应当从中选择一个。(与 406 相关，查看 http 的内容协商机制)
  • 301 Moved Permanently
    • 请求资源的 URL 已永久更改。在响应中给出了新的 URL。
  • 304 Not Modified
    • 这是用于缓存的目的。它告诉客户端响应还没有被修改，因此客户端可以继续使用相同的缓存版本的响应。
  • 400 Bad Request
    • 由于被认为是客户端错误（例如，错误的请求语法、无效的请求消息帧或欺骗性的请求路由），服务器无法或不会处理请求。
  • 401 Unauthorized
    • 从语义上来说，这个响应意味着"unauthenticated"。也就是说，客户端必须对自身进行身份验证才能获得请求的响应。
  • 403 Forbidden
    • 客户端没有访问内容的权限，因此服务器拒绝提供请求的资源。与 401 Unauthorized 不同，服务器知道客户端的身份。
  • 404 Not Found
    • 服务器找不到请求的资源。在浏览器中，这意味着无法识别 URL。在 API 中，这也可能意味着端点有效，但资源本身不存在。
  • 405 Method Not Allowed
    • 服务器知道请求方法，但目标资源不支持该方法。例如，API 可能不允许调用 DELETE 来删除资源。
  • 406 Not Acceptable
    • 当 web 服务器在执行服务端驱动型内容协商机制后，没有发现任何符合用户代理给定标准的内容时，就会发送此响应
  • 407 Proxy Authentication Required
    • 类似于 401 Unauthorized 但是认证需要由代理完成。
  • 500 Internal Server Error
    • 服务器遇到了不知道如何处理的情况。
  • 501 Not Implemented
    • 服务器不支持请求方法，因此无法处理。服务器需要支持的唯二方法（因此不能返回此代码）是 GET 和 HEAD.
  • 502 Bad Gateway
    • 此错误响应表明服务器作为网关需要得到一个处理这个请求的响应，但是得到一个错误的响应。
  • 503 Service Unavailable
    • 服务器没有准备好处理请求。常见原因是服务器因维护或重载而停机。请注意，与此响应一起，应发送解释问题的用户友好页面。
  • 504 Gateway Timeout
    • 当服务器充当网关且无法及时获得响应时，会给出此错误响应。
  • 510 Not Extended
    • 服务器需要对请求进行进一步扩展才能完成请求。
  • 511 Network Authentication Required
    • 指示客户端需要进行身份验证才能获得网络访问权限。

虽然摘自 MDN 的请求方法部分，但是中英文的内容有很多不一致的地方，内容是以因为为准。但是英文的也不一定对。

ref