HTTP和REST基础《综合版：HTTP方法和响应码》

HTTPとRESTの基本『網羅版：HTTPメソッドとレスポンスコード』

首先

参考网站：HTTP 语义（通用基础）RFC 9110 — HTTP 语义
参考网站：面向开发人员的 Web 技术 > HTTP 响应状态代码
参考网站：Wiki HTTP 状态码
参考书：支持 Web 的技术 - HTTP、URI、HTML 和 REST（WEB+DB PRESS plus）
参考书：O'Reilly 日本 RESTful Web 服务

它是根据每个文献进行总结的。在“3. HTTP 响应代码概述”之后，有一些接近引号的部分，但也有很多部分被重写或重新配置。

我之所以想写这篇文章，是因为当我被问及状态码时，我无法正确回答。
我很累，但我明白了很多。

基于此，接下来我想写一篇关于RESTful API设计的文章。

正文如下。

一、HTTP/TCP/IP/REST基础

HTTP 是一种基于 TCP/IP 的无状态协议。它现在在 HTTP 核心规范 (RFC 9110) 中指定。

HTTP (Hypertext Transfer Protocol) 名义上是一种传输超文本的协议，但实际上它不仅用于 HTML 和 XML 等超文本，还用于静态图像、音频、视频 JavaScript 程序、PDF 和各种办公文档文件，任何可以处理的数据都可以传输。

HTTP 是 Web 的底层协议，提供了 REST 的关键特性，例如统一的接口和无状态的存活缓存。

HTTPとRESTの基本『網羅版：HTTPメソッドとレスポンスコード』

1-1. REST (REpresentational State Transfer) 的四个原则

可寻址性

最重要的。能够通过 URI 直接指向资源的属性。确保所有信息都由唯一的 URI 表示。没有它，连接和统一的界面是不可能的

连接性

一个资源可以包含“到另一个资源的链接”，并且包含一个链接可以“连接到另一个资源”。

统一接口

对所有资源获取、创建、更新和删除操作使用 HTTP 方法。指定资源操作和过程，例如“GET”用于获取，“POST”用于创建，“PUT”用于更新，“DELETE”用于删除。只有在上述两个属性得到保证后才有价值的属性

无国籍状态

所有 HTTP 请求在本质上都是完全独立的，不会执行会话等状态管理。这并不是那么重要。 Web 服务需要使用 cookie 进行会话管理。

1-2. 万物皆有的抽象〇〇

REST 实现了一切都是〇〇的抽象。在 REST 中，定义了“一切都是 URI”，可以进行各种各样的资源操作和处理，例如“GET”用于获取，“POST”用于创建，“PUT”用于更新，“DELETE”用于删除，用四个动词表达和约束。

这个特性在其他领域也可以看到。

一切都是文件 (Unix)
一切都是关系/集合 (RDB/SQL)

为了用相同的机制表达各种事物，我们应用强大的限制和抽象来简化，减少接口的行为和可以做的事情，并通过统一的方式提供它来提高可重用性和可重连接性。

任何人都可以使用“GET”、“POST”、“PUT”和“DELETE”来指定和操作网络上的所有资源，无论客户端是谁，连接目的地是什么，或者遗留系统。变成。

报价来源：HTTP 语义（通用基础）RFC 9110 — HTTP 语义

HTTP 请求的目标称为资源。 HTTP 不限制资源的性质——它只定义了与资源交互时可以使用的接口。每个资源都由一个 URI（统一资源标识符）标识。

1-3. 什么是资源？

网络上存在的任何和所有具有名称的信息
Web 服务器必须以特定语言（英语、日语）和格式（XML、JSON）发送资源。这种形式的资源被称为“资源的表示”。
世界各地的资源在其 URI 中都有唯一的名称。所有资源都由 URI 表示。 URI 表示资源本身。

URI 代表“统一资源标识符”。 Uniform Resource Identifier，标识资源的ID
使用 URI，程序可以访问由资源表示的信息（可寻址性）
前任。http://www.example.com:8080/news/index.htm?page=2&msg=yes#hot

https：
表示使用的是http协议方案。还有 https:、ftp:、data:、file: 等。

//
授权地址的根部分。从...开始 ”//”。

w w。啊议员。小米
主机（主机）目标服务器名称

：8080
port 要访问的服务器的端口号

/news/index.htm
path 指定指定权限内的访问目的地。通过服务器公共区域内的目录名和文件名。

?page=2&msg=yes
查询路径中访问的更精细识别。在服务器上运行的程序的指令和指令通常是编写的。

#热
也称为片段锚。指定除主要内容外的部分和替代表达式。它通常不传输到服务器，在客户端（浏览器）处理服务器发送的信息时使用。

1-4. URI、URL 和 URN

UniformResourceIdentifier : 统一资源标识符

统一资源定位器
位置的编写规则

统一资源名称
编写永久标识名称的规则

有这两个都是URI。换句话说，“可寻址”意味着统一资源标识符使其独一无二，并使其易于指向存在于 Web 上的数据。

1-5. 什么是 TCP/IP

HTTP 基于 TCP/IP。 TCP（传输控制协议）和IP（互联网协议）是构成互联网基础的重要网络协议。

分层协议

层姓名标准（协议）主要使用示例在电脑上处理

4层应用层 HTTP、HTTPS、SMTP、POP3、
IMAP4、DHCP、DNS
SSH、SMTP 等网页浏览、电子邮件、文件传输、名称解析等。通讯应用程序

3层传输层 TCP、UDP、NetWare/IP 等 TCP/UDP通讯方式选择
（将数据分发到适当的应用程序）操作系统

2层互联网层 IP、ARP、RARP、ICMP等路由，端到端通信
使用 IPv4 或 IPv6 连接操作系统

1层网络
接口层以太网局域网
如 MAC 地址和以太网
物理电缆等通信方式设备、驱动程序、网卡

1-5-1. 分层协议

互联网的网络协议是分层的，如果每一层都抽象出来并实现，那么上层就可以在不受下层细节影响的情况下实现，比如物理线缆是金属的还是光缆的。

1-5-2. 网络接口层

在同一网络内传输数据
最低的网络接口层是物理电缆或网络
这部分对应于工作适配器。

1-5-3. 互联网层

在多个网络之间传输数据
它是与连接许多网络并传输数据的路由器相对应的部分。

该层负责在网络上实际交换数据的部分。
是。 IP 在 TCP/IP 中是等价的。在IP中，数据的基本通信单位称为“包”。数据以包为单位交换，以指定的IP地址为目的，我只保证数据通过自己的网络接口发出。我们不保证发送的数据将通过许多路由器到达最终目的地。

1-5-4. 传输层

将数据分发到适当的应用程序
如果从底层到传输层一切正常，则可以在源应用程序和目标应用程序之间发送和接收数据。主要协议分为TCP和UDP。

即使数据在传输过程中损坏或丢失，TCP 也会检测到这些并重新传输数据以确保可靠通信。

它保证了 IP 没有的数据传输。它是一种与连接目的地的另一方建立连接，检查数据遗漏并保证数据到达的机制。例如，在 Internet 上执行的大多数通信方式，例如浏览网站上的网页和发送和接收电子邮件，都使用 TCP。

端口号决定了 TCP 连接传输的数据将传递给哪个应用程序。端口号是一个从 1 到 65535 的数字。常见的服务器端端口号分配有默认编号，HTTP 默认使用端口 80。

UDP 是一种使用熟悉的功能向对方发送数据的方法。它不是很准确，但它是快速发送数据的好方法。例如，它是一种与网络会议和视频站点的视频和音频通信方法进行实时通信的方法。因此，当数据通信发生错误时，不是重复播放，而是中断视频和音频，视频和音频实时流动。

TCP UDP

通讯方式连接类型数据图类型

特征强调确定性强调即时性

可靠性高低的

使用速度低速高速

使用示例网页浏览、电子邮件等
一般如何使用互联网 IP电话、视频分发、网络会议等
如何强调实时性

1-5-5. 应用层

决定应用程序处理的数据的格式和程序
应用层是实现诸如邮件、DNS 和 HTTP 等具体 Internet 应用程序的层。使用 TCP 创建程序时，通常使用一个名为 Socket 的库。套接字是抽象网络上数据交换的API，具有发送和断开接收等基本功能。 HTTP 服务器和浏览器是使用套接字实现的。由于应用程序基本上是由人类处理的，它们代表了人类可以识别的字符和图像等数据。主要协议有“HTTP”、“SMTP”、“POP3”、“IMAP4”、“DHCP”、“DNS”等。

HTTP 用于 Web 浏览器，而 SMTP 和 POP3 用于电子邮件软件。 DHCP 和 DNS 充当互补协议，为进行应用程序通信做准备。大多数编程语言都附带了一个标准实现 HTTP 的库，因此使用套接字独立实现 HTTP 似乎几乎是不可能的。但是，在开发 Web 服务和 Web API 时，
协议级别，例如框架行为和设置参数
你需要知道它是如何工作的。

1- 6. HTTP 方法（GET/POST/PUT/DELETE）

客户端如何将其意图传达给服务器？

服务器如何知道特定请求是用于检索某些数据，而不是删除它或用其他东西覆盖它？

与数据操作相关的信息称为方法信息。在 Web 服务中传达方法信息的一种方法是将其包含在 HTTP 方法中。
HTTP 方法名称的一大优点是它们是标准化的并且可以在全球范围内使用。
客户端和资源之间的所有交互都由一些基本的 HTTP 方法处理。任何资源都支持部分或全部这些方法，并且这些方法对于支持它们的任何资源都一样。

1-6-1. GET -> 获取资源

“获取一些数据”

GET请求是一种获取指定URI信息的方法。请求有关资源的信息。信息以一系列标头和表示形式发送。客户端从不发送带有 GET 请求的表示。

如果可以识别资源，则发送响应代码 200（OK）和表示。始终支持条件 GET。

它可能是最常用的，包括获取网页、图像、视频和提要。

1-6-2. POST -> 创建和添加资源

仅次于 GET 的第二个最常用的

POST 请求是尝试从现有资源创建新资源。在数据结构意义上，现有资源可以是新资源的父级，就像树的根是其所有叶节点的父级一样。

与 POST 请求一起发送的表示描述了新资源的初始状态。与 PUT 请求一样，不需要在 POST 请求中包含表达式。 POST 请求还可用于附加到现有资源的状态，而无需创建全新的资源。

解析表达式，选择适当的 URI，并在那里创建一个新资源。

创建子资源

POST 的一个典型功能是能够为资源创建子资源。用于发布博客文章。

向资源中添加数据

虽然不像创建子资源那样主要用途，但您也可以向现有资源添加数据。

其他方法无法处理的处理

POST 的第三个功能是执行其他方法无法处理的处理。一个示例是显示搜索结果的 URI。
http://example.jp/search?q={検索キーワード}
正常情况下，你可以GET这个URI，但是如果搜索关键字很长，你不能通过在URI中插入关键字来使用GET方法。这是由于实现 URI 的 2000 个字符限制。

在这种情况下使用 POST。 GET 在 URI 中包含关键字，而 POST 可以将它们包含在请求正文中。因此，它可以对应任何长关键字。

发送响应代码 201(Created) 并在 Location 标头中设置新资源的 URI。如果没有提供足够的信息来创建资源，则发送响应代码 400（错误请求）。如果提供的资源的状态与现有资源冲突，请发送响应代码 409（冲突）并添加指向相关资源的 Location 标头。解析 POST 表示以添加到资源。如果表达式没有意义，请发送响应代码 400（错误请求）。否则，更改资源状态以填充表示信息。发送响应代码 200（确定）。

1-6-3. PUT -> 更新，创建资源

“用不同的数据覆盖”

PUT 请求是关于资源状态的客户端建议。客户端通常使用 PUT 请求发送表示，服务器尝试创建或修改资源的状态以匹配表示的内容。没有表示的 PUT 请求只是一个资源存在于特定 URI 的断言。

更新资源
使用 PUT 请求发送新的内容表示，覆盖资源的现有表示。

创建资源
创建可以用 POST 完成的资源也可以用 PUT 完成。例如，假设 [http://example.jp/newitem] 尚不存在。此时，PUT 是对不存在的 URI 的请求，因此服务器将其解释为创建新资源。如果请求成功，则返回[201 Created]。如果 /newitem 存在，它只会覆盖。

如果资源已存在，则解析表达式并对资源的状态进行一系列更改。如果更改会使资源处于不完整或不一致的状态，则发送响应代码 400（错误请求）。

如果更改导致资源状态与其他资源发生冲突，则发送响应代码 409（冲突）。如果更改资源状态会使资源在不同的 URI 上可用，请发送响应代码 301 (MovedPermanently) 并在 Location 标头中设置新的 URI。否则，发送 200 (OK) 响应代码。如果 URI 已更改，对旧 URI 的请求应返回响应代码 301（永久移动）、404（未找到）或 410（已消失）。

对不匹配任何资源的 URI 的 PUT 请求可以通过两种方式处理：返回状态代码 404（未找到）或在该 URI 处创建资源。如果创建新资源，则解析表示，根据它配置资源的初始状态，并发送响应码 201（已创建）。如果没有足够的信息来创建新资源，则发送响应代码 400（错误请求）。

1-6-4. 删除 -> 删除资源

“删除该数据”

DELETE 请求是客户端建议资源不再存在。客户端从不发送带有 DELETE 请求的表示。发送 200（OK）响应代码。

2.什么是HTTP响应状态码？

HTTP 响应状态代码指示特定 HTTP 请求是否成功完成。一个三位数字代码，表示来自服务器的响应的含义。响应分为五类。
信息响应 (100–199)

成功响应 (200–299)

重定向消息 (300–399)

客户端错误响应 (400–499)
服务器错误响应 (500–599)
2-1. HTTP响应大致分为三种
HTTP 响应代码

响应标头
身体
curl -I https://twitter.com/yoshitaro_yoyo

HTTP/2 200 
date: Thu, 27 Oct 2022 15:01:10 GMT
perf: 7626143928
expiry: Tue, 31 Mar 1981 05:00:00 GMT
pragma: no-cache
server: tsa_m
set-cookie: guest_id_marketing=v1%3A166688287077136753; Max-Age=63072000; Expires=Sat, 26 Oct 2024 15:01:10 GMT; Path=/; Domain=.twitter.com; Secure; SameSite=None
set-cookie: guest_id_ads=v1%3A166688287077136753; Max-Age=63072000; Expires=Sat, 26 Oct 2024 15:01:10 GMT; Path=/; Domain=.twitter.com; Secure; SameSite=None
set-cookie: personalization_id="v1_ihdlBnYARwM8D3YgWju5ow=="; Max-Age=63072000; Expires=Sat, 26 Oct 2024 15:01:10 GMT; Path=/; Domain=.twitter.com; Secure; SameSite=None
set-cookie: guest_id=v1%3A166688287077136753; Max-Age=63072000; Expires=Sat, 26 Oct 2024 15:01:10 GMT; Path=/; Domain=.twitter.com; Secure; SameSite=None
content-type: text/html; charset=utf-8
x-powered-by: Express
cache-control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0
last-modified: Thu, 27 Oct 2022 15:01:10 GMT
x-frame-options: DENY
x-transaction-id: 9101702a5e93556d
x-xss-protection: 0
x-content-type-options: nosniff
content-security-policy: connect-src 'self' blob: https://*.pscp.tv https://*.video.pscp.tv https://*.twimg.com https://api.twitter.com https://api-stream.twitter.com https://ads-api.twitter.com https://aa.twitter.com https://caps.twitter.com https://pay.twitter.com https://sentry.io https://ton.twitter.com https://twitter.com https://upload.twitter.com https://www.google-analytics.com https://accounts.google.com/gsi/status https://accounts.google.com/gsi/log https://app.link https://api2.branch.io https://bnc.lt wss://*.pscp.tv https://vmap.snappytv.com https://vmapstage.snappytv.com https://vmaprel.snappytv.com https://vmap.grabyo.com https://dhdsnappytv-vh.akamaihd.net https://pdhdsnappytv-vh.akamaihd.net https://mdhdsnappytv-vh.akamaihd.net https://mdhdsnappytv-vh.akamaihd.net https://mpdhdsnappytv-vh.akamaihd.net https://mmdhdsnappytv-vh.akamaihd.net https://mdhdsnappytv-vh.akamaihd.net https://mpdhdsnappytv-vh.akamaihd.net https://mmdhdsnappytv-vh.akamaihd.net https://dwo3ckksxlb0v.cloudfront.net https://media.riffsy.com https://*.giphy.com https://media.tenor.com https://c.tenor.com ; default-src 'self'; form-action 'self' https://twitter.com https://*.twitter.com; font-src 'self' https://*.twimg.com; frame-src 'self' https://twitter.com https://mobile.twitter.com https://pay.twitter.com https://cards-frame.twitter.com https://accounts.google.com/ https://client-api.arkoselabs.com/ https://iframe.arkoselabs.com/  https://recaptcha.net/recaptcha/ https://www.google.com/recaptcha/ https://www.gstatic.com/recaptcha/; img-src 'self' blob: data: https://*.cdn.twitter.com https://ton.twitter.com https://*.twimg.com https://analytics.twitter.com https://cm.g.doubleclick.net https://www.google-analytics.com https://maps.googleapis.com https://www.periscope.tv https://www.pscp.tv https://media.riffsy.com https://*.giphy.com https://media.tenor.com https://c.tenor.com https://*.pscp.tv https://*.periscope.tv https://prod-periscope-profile.s3-us-west-2.amazonaws.com https://platform-lookaside.fbsbx.com https://scontent.xx.fbcdn.net https://scontent-sea1-1.xx.fbcdn.net https://*.googleusercontent.com https://imgix.revue.co; manifest-src 'self'; media-src 'self' blob: https://twitter.com https://*.twimg.com https://*.vine.co https://*.pscp.tv https://*.video.pscp.tv https://dhdsnappytv-vh.akamaihd.net https://pdhdsnappytv-vh.akamaihd.net https://mdhdsnappytv-vh.akamaihd.net https://mdhdsnappytv-vh.akamaihd.net https://mpdhdsnappytv-vh.akamaihd.net https://mmdhdsnappytv-vh.akamaihd.net https://mdhdsnappytv-vh.akamaihd.net https://mpdhdsnappytv-vh.akamaihd.net https://mmdhdsnappytv-vh.akamaihd.net https://dwo3ckksxlb0v.cloudfront.net; object-src 'none'; script-src 'self' 'unsafe-inline' https://*.twimg.com https://recaptcha.net/recaptcha/ https://www.google.com/recaptcha/ https://www.gstatic.com/recaptcha/ https://client-api.arkoselabs.com/ https://www.google-analytics.com https://twitter.com https://app.link https://accounts.google.com/gsi/client https://appleid.cdn-apple.com/appleauth/static/jsapi/appleid/1/en_US/appleid.auth.js  'nonce-ZmQ3NmJlMzEtNTU3ZS00OTI0LTkwMDgtNjQ1N2RjZmI1Y2Zi'; style-src 'self' 'unsafe-inline' https://accounts.google.com/gsi/style https://*.twimg.com; worker-src 'self' blob:; report-uri https://twitter.com/i/csp_report?a=O5RXE%3D%3D%3D&ro=false
strict-transport-security: max-age=631138519
cross-origin-opener-policy: same-origin-allow-popups
cross-origin-embedder-policy: unsafe-none
x-response-time: 183
x-connection-hash: 7d904b5ae825c89eec55789dc9aab3357cc5950ed814a07b1b04ea7047ec3e8a
2-1-1. HTTP 响应码

响应消息的第一行称为“状态行”，由协议版本 (HTTP/2)、状态代码 (200) 和文本短语 (OK) 组成。
HTTP/2 200 OK
状态代码是一个数字代码，可以通过编程方式处理请求的结果。
以等级表示。 “200”表示请求成功。

2-1-2. 响应头

响应消息的第二行和后续行是标题。
Content-Type 标头指定 HTML MIME（多用途 Internet 邮件扩展）媒体类型 (text/html) 及其字符编码方法 (utf-8)。
Content-Type: text/html; charset=UTF-8
2-1-3. 身体

在标题之后，正文包含 HTML。
它也被称为表示，因为它告诉 Web 浏览器如何处理文档。在这种情况下，它实际上包含了正文，正文是 GET 请求的结果。

响应头 Content-Type 指示正文的媒体类型，例如，如果媒体类型是 text/html。 Web 浏览器承认正文可以呈现为 HTML 文档（网页）。最常见的媒体类型是文本文档 (text/html)、结构化数据文档 (application/xml) 和图像 (image/jpeg)。其他关于 REST 和 HTTP 的文献有时将媒体类型称为“MIME 类型”、“内容类型”或“数据类型”。

从现在开始，我将全面描述响应代码和相关标头。重新配置并写入如下来源。

参考网站：HTTP 语义（通用基础）RFC 9110 — HTTP 语义

参考网站：面向开发人员的 Web 技术 > HTTP 响应状态代码

参考网站：Wiki HTTP 状态码

参考书：支持 Web 的技术 - HTTP、URI、HTML 和 REST（WEB+DB PRESS plus）

参考书：O'Reilly 日本 RESTful Web 服务

3. HTTP响应代码概述

服务器尝试将问题通知客户端。由于响应代码不是文档或元数据的一部分，因此客户端可以通过查看响应的第一行来判断是否发生了错误。

官方的 HTTP 响应代码有 41 个，其中大约 10 个对于日常使用很重要。由于它是基于一本旧书，它可能与现在的情况有所不同，但我认为它并没有太大变化，因为从技术角度来看它是一个通用部分。

引用书籍：O'Reilly 日本 RESTful Web 服务
许多 Web 服务滥用 HTTP 状态代码。这是因为传统 Web 很少使用 HTTP 状态码。

〜省略〜

计算机程序无法仅通过查看文档来确定其确切含义。同一个文档，视情况而定，可能是错误消息或 GET 请求的有效结果。我们需要某种方式来表明这是查看响应的正确方式。我们不能将此信息添加到实体主体文档中，否则我们必须了解文档才能提取信息。因此，HTTP 响应代码在可编程网络中非常重要。响应代码告诉客户端如何处理包含在实体正文中的文档，或者如果它不理解该文档该怎么办。

〜省略〜

客户端或客户端和服务器之间的中介（例如防火墙）可以通过查看响应的前三个字节来了解 HTTP 请求的状态。

〜省略〜

问题在于，除了官方的 41 个响应代码之外，还有 WebDAV 等标准规定的响应代码。许多响应代码很少使用，其中两个从未使用过，有些仅通过吹毛求疵的细节来区分。对于那些熟悉传统 Web 的人（我们所有人）来说，响应代码的多样性令人费解。

何时使用

严重性

相关的 HTTP 方法

我想描述以上内容。但是，由于它们太多，我想重点关注那些相对重要的。

3-1. 最少需要 3~7 个代码

如果您想保持较低的状态码数量，只需提供 3 个状态码。仅它们就可以传达客户处理响应所需知道的基本信息。

❐ 200（确定）

一切都很好。当实体主体包含文档时，它是某种资源的表示。

❐ 400（错误请求）

客户端有问题。如果实体主体包含文档，则为错误消息。希望客户能够理解错误信息并据此解决问题。

❐ 500（内部服务器错误）

服务器端有问题。如果实体主体包含文档，则为错误消息。该消息没有多大意义，因为客户端无法解决服务器的问题。还有四个在 Web 服务中特别常见的错误代码。

❐ 301（永久移动）

当客户端执行某些更改资源 URI 的操作时发送。当客户端请求旧 URI 时也会发送。

❐ 404（未找到）和 410（已消失）

当客户端请求与资源不匹配的 URI 时发送。当服务器不知道客户端请求什么时使用 404。当资源曾经存在但服务器知道它不再存在时使用 410。

❐ 409（冲突）

当客户端尝试执行使一个或多个资源处于不一致状态的操作时发送。

4.HTTP响应码详情

从这里开始，我们将分别介绍 100 到 500 个响应代码。

4-1. 1xx：信息响应（处理）

1xx 系列响应代码仅用于与 HTTP 服务器的协商。
“收到请求。处理继续。”

❐ 100 继续

严重性：中
相关 HTTP 方法：全部
身体：无
继续。客户端可以继续请求。表示应重新发送初始请求，包括客户端原始请求中省略的表达式。客户不必担心发送最终会被拒绝的表示。

例如，客户端发出一个带有 Expect: 100-continue 标头的请求，当请求标头发送完毕后，服务器返回 100 Continue。这可以避免您发送不必要的巨大请求。

首先，客户端发送一个带有 Expect 标头的请求。
POST /files/bar.txt HTTP/1.1
Host: example.jp
Expect: 100-continue
Content-length: 524288000
◎ 标题期望

类型：请求头
严重性：中
值：100-继续
此标头要求客户端将资源 /files/bar.txt 发布到服务器。所以这不是真正的传输。您可以通过在此请求标头中设置字符串“100-continue”来询问。

在这种情况下，服务器查看 Content-length 来决定是否接受 500MB 的文件提交。

如果可能，如果客户端应该“继续”并发送真正的请求，服务器应该发送响应代码 100（继续）。客户端从那里再次发送一个 POST 请求，省略 Expect 并在正文中发送一个 500MB 的文件。

如果不允许，如果客户端不应继续下一步，则服务器应发送响应代码 417（预期失败）。
文件很大，或者 /files/bar.txt 的资源不可写，或者客户端提供的凭据不正确。

4-2. 2xx：响应成功

2xx 系列响应代码表示处理成功。
“请求已收到、理解并接受”

❐ 200 确定“确定”

严重性：非常高
相关 HTTP 方法：全部
正文：对于 GET 请求，客户端请求的资源的表示。对于使用其他方法的请求，所选资源的当前状态的表示，或者对所采取的操作或结果的描述

在大多数情况下，这是客户想要的代码。表示客户端请求的动作在服务器上是成功的，在更具体的 2xx 系列代码中是不合适的。请求的信息与响应一起返回。当页面正确呈现时，大多数浏览器都会返回此状态代码。

GET：在消息正文中读取和传输的资源。

HEAD：表示头包含在没有消息正文的响应中。

PUT 或 POST：在消息正文中发送表示操作结果的资源。

TRACE：消息正文包含服务器收到的请求消息。

❐ 201 已创建

严重性：高
相关 HTTP 方法：POST/PUT
正文：服务器在创建新资源以响应客户端请求时发送此状态代码。

表示请求成功并创建了新资源和指向该资源的链接。如果请求是 POST，则 Location 标头将包含新资源的绝对 URI。如果 Location 标头用于将资源的实际位置传达给客户端，则可以包含资源的表示。

◎ 标题位置

类型：响应头
严重性：非常高
值：包含新资源的合法 URI
指示重定向时的目标 URI，或创建新的 URI。

这是一个具有许多相关功能的多用途标头。与响应代码 3xx（重定向）密切相关，围绕 HTTP 重定向的大部分混淆与此标头的解释方式有关。

此标头通常告诉客户端使用哪个 URI 来访问资源。可能是客户端的请求创建了资源（响应码201（Created）），或者资源的URI改变了（301（Moved Permanently）），客户端请求了URI
还不知道或者，客户端可能使用了一个不完全正确的 URI，但由于略有不同，服务器没有意识到错误。这种情况下的响应代码也可以是 301、307（TemporaryRedirect）或 302（找到）。

Location 值可能只是默认的 URI。例如，这是对 300（多项选择）等模糊请求的众多解决方案之一。此外，位置值可能指向提供附加信息的其他资源，而不是客户端尝试访问的资源，例如 303（请参阅其他）。

因此，此标头仅在某些 HTTP 响应代码的上下文中才有意义。

❐ 202 已接受

公认。请求已被接受，但处理尚未完成。

严重性：中
正文：至少估计何时处理请求，如果客户端之后看不到请求
相关方法：全部
响应标头：位置/重试后

所有获取处理结果的资源链接和预计处理时间都表明客户端的请求已被接受，但服务器不能或不会实时处理。这是模棱两可的。这是因为在 HTTP 中没有办法事后发送异步响应，指示处理请求的结果。通常在通过 POST 或 PUT 创建或更新资源时返回可能需要很长时间。

用于异步处理的 RESTful 系统的一个重要部分是当请求触发异步操作、实际操作或耗时过长以至于让客户端等待毫无意义的操作时的适当响应。用于批处理。

您应该将未完成的请求作为资源提供，以便客户端稍后可以检查它。 Location 标头可以设置为此资源的 URI。

◎ Header Retry-After

类型：响应头
严重性：低到中
相关HTTP方法：GET
值：日期时间或数字（秒）

此标头的值指示客户端应重试多长时间，或应等待多少秒。

此标头通常伴随一个 413（请求实体太大）响应代码，指示错误或 5xx 系列之一（服务器端错误）。此标头表示服务器无法立即处理请求，但稍后可能能够处理相同的请求。

如果服务器为所有客户端选择了具有相同规则的 Retry After 值，它只会确保同一个客户端稍后会以相同的顺序发送相同的请求，可能只是重复问题。服务器需要使用某种随机方法改变 Retry After 值，类似于以太网退避期。

❐ 204 无内容

严重性：高
相关 HTTP 方法：POST / PUT / DELETE
身体：无

无内容。表示请求成功，但是没有内容返回给客户端。

当服务器拒绝返回状态消息或表示时，通常会为 PUT POST DELETE 请求发送此状态代码。服务器还可以发送 204 连同 GET 请求，以指示请求的资源存在但为空表示。

它通常用于 Ajax 应用程序中，当表单的内容通过 POST 方法发送但 Web 浏览器屏幕没有刷新时，以响应 DELETE 。服务器使用此状态代码表示输入已被接受，但客户端不应更改 UI 元素。

❐ 206 部分内容

重要性：对于支持部分 GET 的服务非常高，否则低
相关HTTP方法：GET
正文：对于部分 GET 请求，表示客户端请求的指定范围的资源。对于其他请求，所选资源的当前状态的表示或所采取的操作的描述。
请求标头：范围、If-Range
响应标头：内容范围

与 200（OK）相同，但表示对使用 Content-Range 请求标头的请求的响应。客户端通常发送部分 GET 请求以恢复大型二进制表示的中断下载。

您可以通过在执行 GET 时使用 Range 标头指定资源的范围（以字节为单位）来仅获取部分资源。这称为“部分 GET”。此状态代码表示部分 GET 成功。响应的 Content-Range 标头包含 Range 标头指定的部分。

使用下载工具等进行分割下载或恢复时返回。

带条件的部分 GET 不经常使用。这是因为客户端很少从大型表示中获取几个字节，然后再获取相同的字节。

◎ 范围标头

类型：请求标头
严重性：中
相关HTTP方法：GET
价值：你想得到的部分

此标头表示客户端希望仅请求资源表示的一部分。以字节为单位指定所需的宽度。

客户端通常会发送此标头，因为它之前尝试下载大型表示并断开连接。现在再次请求以获取其余的表示。如果自上次请求后表示已更改，则您需要从头开始执行 GET。

◎ 标题内容-范围

类型：响应头
严重性：中到高
相关HTTP方法：GET
值：字节宽度

此响应标头指示当客户端使用 Range 请求标头发送部分 GET 请求时，客户端想要检索表示的哪一部分。

4-3. 3xx：重定向消息

3xx 状态码表示需要做更多的工作才能获得客户的要求

完成请求所需的进一步处理

重定向最常用于 GET 请求，通常表示客户端如果不向其他某个 URI 发送第二个 GET 请求就无法获得所需的表示。第二个 URI 在 Location 响应标头中发送。

301（永久移动）、302（找到）、303（查看其他）和 307（临时重定向）都非常相似，因此这些是最需要注意的响应代码。许多应用程序不加选择地使用这些状态代码作为将客户端从一个 URI 移动到另一个 URI 的手段，从原始资源的角度淡化它们的含义。

❐ 301 永久移动

严重性：中
相关 HTTP 方法：全部
正文：包含指向目标 URL 的链接等的 HTML。
请求标头：服务器应使用有效 URI 附加位置

服务器知道客户端试图访问什么资源，但请求中使用的 URI 不处理该资源。请求客户端注意到新的 URI 并在以后的请求中使用它。

当请求的资源已永久移动到新的 URI 时返回，并且 Location: 标头指示目标 URL。

服务器知道客户端试图访问什么资源，但请求中使用的 URI 不处理该资源。请求客户端注意到新的 URI 并在以后的请求中使用它。

在网站移动时使用。这也适用于 HTTP 到 HTTPS 的传输。另外，在目录对应的URL末尾不写/而不是文件访问时返回。此状态码可用于防止旧 URI 在 URI 更改时变为无效。

❐ 302 找到“发现”

严重性：了解此状态代码非常重要，尤其是在您编写客户端时。但是，不鼓励使用此状态码。
相关HTTP方法：POST
正文：包含指向目标 URL 的链接等的 HTML。
请求标头：服务器应使用有效 URI 附加位置

此状态代码是大多数与重定向相关的混淆的根本原因。

状态码表示最初请求的资源暂时不存在于该 URL 中，客户端应将请求重新发送到 Location 标头指示的另一个 URI，而不更改方法。

但是，例如，当您希望 Web 浏览器在公告板或 wiki 上发布后转发到另一个 URL 时，也会使用此代码，因此 302 is Found 并且将 302 的原始含义的状态代码重新定义为 307 Temporary已重定向，因此不再建议使用此状态码。

区别在于客户端在收到 302 响应 PUT、POST 或 DELETE 请求时应该做什么。

为了消除这种歧义，HTTP 1.1 将此响应代码重命名为“找到”并创建了响应代码 307。虽然这个响应代码今天仍然被广泛使用，但它是模棱两可的，鼓励服务发送 303 而不是 307。除非您正在与不理解 303 或 307 的 HTTP 1.0 客户端交谈。

❐ 303 查看其他

严重性：高
相关HTTP方法：POST
正文：包含指向目标 URL 的链接等的 HTML。
请求标头：服务器应使用有效 URI 附加位置

当请求的响应存在于另一个 URL 时返回。表示可以从Location头指示的URI中用GET获取请求的处理结果。当请求的资源确实位于该 URL，但响应是另一个资源时使用。正如在 302 的解释中所提到的，它是作为一个代码引入的，当您希望 Web 浏览器在公告板或 Wiki 上发布后转发到另一个 URL 时应该使用该代码。

状态码 303 是标准化资源的好方法。可以通过许多 URI 提供资源，但每个表示只有一个“真实”URI。所有其他 URI 使用 303 来指向表示的合法 URI。

❐ 304 未修改

严重性：高
相关HTTP方法：GET
身体：无
响应标头：日期 ETag 内容-位置

缓存标头：过期、缓存控制、变化

将此用于缓存。此响应代码向客户端指示该响应尚未被修改。所以客户端会继续使用缓存的响应。

如果客户端使用带有周日日期的 If-Modified-Since 标头发出请求，并且表示自周日以来没有更改，那么 304 就可以了。 200（OK）也可以，但是再次发送表示会浪费带宽。因为客户已经有了那个表示。

◎ 标题日期

类型：请求和响应标头
重要性：请求高，响应必需
值：日期时间

作为请求头，它代表了请求在客户端时间中发送的时间。作为响应头，它表示请求在服务器时间内完成的时间。缓存使用日期作为响应标头。

◎ 标头ETag

类型：响应头
严重性：非常高
值：表示 Etag 的字符串

更新资源时更改的值。

ETag 值是一个不透明的字符串，用于标识表示的特定版本。当表示改变时，ETag 也会改变。应尽可能使用此标头发送对 GET 请求的响应。客户端可以在后续的条件 GET 请求中使用 ETag 头的值作为 IfNone Match 的值。

如果表达式没变，说明ETag没变，所以这里可以指定多种语言。

◎ Header Cache-Control

类型：请求和响应标头
严重性：中
值：标识符 no-cache、max-age 等。

指示客户端和服务器应遵循的缓存策略。

此标头包含对客户端和服务器之间的任何缓存（包括客户端或服务器上的缓存）的指令。微调数据的缓存方式和删除时间。

◎ 标头过期

类型：响应头
严重性：中
值：日期时间

这个标头告诉客户端，或者服务器和客户端之间的代理，响应可以被缓存到一定的时间。

❐ 307 临时重定向

严重性：高
相关 HTTP 方法：全部
正文：包含指向目标 URL 的链接等的 HTML。
响应标头：位置

表示请求的 URI 不存在，客户端应将请求重新发送到 Location 标头指示的不同 URI，而不更改方法。 HTTP 1.1 中添加了此状态代码，以重新定义 302 Found 的含义，并正确使用它。由于302的非标准使用猖獗，重新定义了302的原始用法。但毕竟很少有浏览器能正确实现这个状态码。

它与 302 Found 的不同之处在于用户代理不得更改使用的 HTTP 方法。如果您在第一个请求中使用 POST，则必须在下一个请求中使用 POST。

对于 GET 请求，此状态代码与 303 完全相同（请参阅其他），因为请求的唯一内容是服务器发送的表示形式。 307 是对 GET 请求的适当响应的典型情况是服务器想要将客户端定向到镜像站点时。

但是，对于 POST PUT DELETE 请求，此状态码与 303 非常不同，因为服务器预计会采取一些行动来响应请求。 POST PUT DELETE 请求的响应代码为 303 表示处理成功，但没有随该请求发送响应实体主体。如果客户端想要响应的实体主体，它应该向另一个 URI 发送一个 GET 请求。

对 POST PUT DELETE 请求的响应代码 307 意味着服务器甚至没有尝试执行该操作。客户端应将整个请求重新发送到 Location 标头中包含的 URI。

假设你带着空处方去药房。 303开了个药方。请到下一个柜台取药。”药剂师说。 307是一位药剂师，他说：“我不能给你配药，请去隔壁的药房。”

❐ 308 永久重定向

严重性：中
相关 HTTP 方法：全部
正文：包含指向目标 URL 的链接等的 HTML。
请求标头：服务器应使用有效 URI 附加位置

永久移动时返回请求的资源。 Location: 标头指示目标 URL。
由于301的非标准使用猖獗，重新定义了301的原始用法。

4-4. 4xx：客户端错误响应

表示客户端出现问题。身份验证、表示格式或 HTTP 库本身存在问题。您必须在客户端解决问题。

客户端错误来自客户端的请求中有错误

❐ 400 错误请求“请求无效”

严重性：高
相关 HTTP 方法：全部
正文：解释为什么服务器认为问题出在客户端

表示请求语法不正确。当其他 4xx 错误代码不适合时也使用它，并且是通用的客户端错误状态。如果向客户端返回一个未知的 4xx 类型的状态码，规范规定应该以与 400 Bad Request 相同的方式处理。

通常在客户端发送带有 PUT 或 POST 请求的表达式并且表达式格式正确但没有意义时使用。

❐ 401 未经授权的“需要身份验证”

严重性：高
相关 HTTP 方法：全部
正文：（如果由用户提供）指示拒绝凭据的原因以及接受的凭据。如果最终用户可以通过在您的网站上注册或通过创建“用户帐户”资源来获取凭据，则指向注册 URI 的链接很有用。
请求标头：授权
响应头：WWW-Authenticate 头描述了服务器接受的认证类型

客户端试图在未提供正确身份验证信息的情况下操纵受保护的资源。您可能提供了不正确的凭据或没有提供凭据。凭据是相关服务所需的凭据，例如用户名和密码、API 密钥或身份验证令牌。

客户端经常向 URI 发送请求并获得 401 以了解要发送的凭证类型和格式。事实上，HTTP Digest 模式身份验证依赖于这种行为。

如果服务器不希望未经授权的用户知道资源存在，它可能会撒谎并发送 404（未找到）而不是 401。这种情况下的缺点是客户端需要提前知道服务器对该资源需要什么样的身份验证。 HTTP Digest 等身份验证方案不起作用。

◎ 头部授权

类型：请求标头
严重性：非常高
值：凭据

此请求标头包含客户端根据商定方案编码的身份验证信息，例如用户名和密码。服务器解码凭据以决定是否处理请求。理论上，此标头是可扩展的，因此它是任何人都绝对需要的唯一身份验证标头。

最常用的方法是 HTTP Digest，但客户端和服务器可以理解的任何方法都可以。事实上，HTTP 本身已经扩展了非官方的请求标头，例如 X-WSSE，它们在授权之上工作。

◎ Header WWW-Authenticate

类型：响应头
严重性：严重性：非常高
值：认证方式

此标头伴随响应代码 401（未经授权）。表示下次客户端向该 URI 发送请求时，服务器将要求发送身份验证信息。它还指示服务器期望的身份验证类型。身份验证类型包括 HTTP Basic 身份验证、HTTP Digest 身份验证或 WSSE 等非标准身份验证。

❐ 403 禁止“禁止”

严重性：中
相关 HTTP 方法：全部
正文：解释请求被拒绝原因的任何文件

401 Unauthorized 表示客户端未提供正确的凭据。
，而 403 Forbidden 表示由于任何其他原因无法操作该资源。客户端的请求格式正确，但服务器并未尝试处理它。与 401 Unauthorized 不同，客户端的身份是服务器已知的。

当您没有访问权限或主机已被禁止访问时返回。试图从公司外部访问只能从公司内部（内部网）访问的页面。表示资源只能在特定时间段内或从特定 IP 地址访问

但是，返回 403 Forbidden 会向客户端显示资源存在。您还可以使用 404 Not Found 来隐藏资源本身的存在。

如果客户端请求格式正确，为什么这个状态码是 4xx 系列（客户端错误）而不是 5xx 系列（服务器端错误）？这是因为服务器根据请求的性质做出决定，例如发送请求的日期和时间，而不是请求的格式。

❐ 404 未找到

严重性：高
相关 HTTP 方法：全部
正文：解释请求被拒绝原因的任何文件

可能是最著名的 HTTP 状态代码。 404 表示服务器无法将客户端 URI 映射到资源。

将其与稍微有用的 410 (Gone) 进行比较。 Web 服务可以使用响应代码 404 来通知客户端该 URI 是“免费的”。然后，客户端可以向该 URI 发送 PUT 请求以创建新资源。

请注意，404 可能是隐藏 403 或 401 的谎言。也许资源存在，但服务器不想告诉客户端它。在 API 中，这可能意味着目标有效，但资源本身不存在。

❐ 405 方法不允许“方法不允许”

严重性：中
相关 HTTP 方法：全部
正文：解释请求被拒绝原因的任何文件
响应标头：允许

在不允许使用 POST 方法的情况下使用 POST 方法时返回。

客户端尝试使用此资源不支持的 HTTP 方法。例如，只读资源可能只支持 GET 和 HEAD。另一个资源可能支持 GET 和 POST，但不支持 PUT 和 DELETE。

响应将包含一个 Allow 标头，列出此 URI 支持的方法。
Allow: GET, POST
例如，当您向 AtomPub 集合资源发送 PUT 或 DELETE 时，应返回此状态代码。

◎ 标题允许

类型：响应头
严重性：严重性目前很低，但可能很高
**相关HTTP方法：**
**价值： **

此标头是为响应 OPTIONS 请求而发送的，以告知客户端特定 URI 支持哪个统一接口子集。使用 OPTIONS 后，此标头将变得更加重要。

❐ 406 不可接受

严重性：中
相关 HTTP 方法：全部
正文：候选 URL 列表
请求标头：Accept、Accept-Charset、Accept-Language、AcceptEncoding、Accept-Range

服务器可能会发送此响应代码，因为对客户端可以接受的表示形式指定了太多限制（可能使用 Accept-* 请求标头），而服务器无法发送表示形式就是这种情况。服务器可以忽略客户端的硬限制，并简单地发送具有 200（OK）响应代码的更高优先级表示。这就是它通常在传统网络上的处理方式。

示例：服务器只能接受英文或日文，但请求的 Accept-Language: 标头仅包含 zh（中文）。
示例：服务器想要发送 application/pdf，但请求的 Accept: 标头中没有包含 application/pdf。
示例：服务器想要发送一个 UTF-8 文档，但请求的 Accept-Charset: 标头不包含 UTF-8。

◎ 标头接受

类型：请求头
严重性：中
值：媒体类型优先级

客户端发送一个 Accept 头来告诉服务器它想要在其表示中使用的数据格式。一些客户端需要 JSON 表示，其他客户端需要相同数据的 RDF 表示。
将这些信息隐藏在 HTTP 标头中对 Web 浏览器来说很方便，但对于 Web 服务客户端来说不应该是唯一的解决方案。

这并不意味着强加粗略的规则，例如在 HTML 表示中将“.html”附加到 URI（尽管 Rails 会这样做）。但在我看来，信息应该以某种方式包含在 URI 中。此外，如果您还考虑支持 Accept 除此之外，那就太好了（同样是 Rails 的风格）。

◎ Header Accept-Encoding

类型：请求头
严重性：中到高
值：压缩方法优先级

指定客户端理解的压缩方法。客户端发送一个 Accept-Encoding 标头告诉服务器它可以通过使用众所周知的算法（例如 compress 或 gzip）压缩响应实体主体来节省带宽。尽管它的名字，这个标头与字符集编码无关。

❐ 409 冲突

严重性：高
相关 HTTP 方法：PUT / POST / DELETE
正文：您应该添加描述冲突的文档，最好让客户能够解决冲突。
响应标头：位置

该请求无法完成，因为它与当前资源冲突。

表示对资源请求的操作与资源的当前状态不一致。在与其他资源冲突的情况下尝试，例如尝试删除非空目录或使用已在其他地方使用的资源名称时。

当用户尝试丢弃非空数据包时，Amazon S3 会发送此响应代码。

如果冲突的来源是其他资源的存在（例如尝试将用户名重命名为已使用的用户名），则 Location 标头应指向该资源的 URI，从而指向冲突的来源。

❐ 410 Gone“消失”

严重性：中
相关 HTTP 方法：全部
正文：解释请求被拒绝原因的任何文件

资源永久移动或消失。我不知道他去了哪里。
但是由于这个代码没有特殊设置是无法显示的，所以很多网站即使资源消失也会发出404代码。

此响应代码类似于 404 Not Found），但提供了更多信息。没有转发地址时发送，不再复活。当服务器知道所请求的 URI 用于引用资源但不再引用时使用。服务器不知道资源的新 URI。如果是这样，请发送 301（永久重定向）。

与永久重定向一样，响应代码 410 意味着客户端应从其词汇表中删除当前 URI 并停止向该 URI 发送请求。与永久重定向不同，410 无法替代不适当的 URI。它只是消失了。

RFC 2616 建议将响应代码 410 用于限时促销服务和属于不再活跃于服务器站点的个人的资源。

您可能希望在成功的 DELETE 请求后发送此响应代码，但这似乎有点人为。客户端在发送请求之前不知道资源是否已被删除或者它是否不存在。成功的 DELETE 请求的正确响应是 200（OK）。 API 不应尝试为此状态代码强制删除资源。

❐ 412 前提条件失败

严重性：中
相关 HTTP 方法：PUT / POST
正文：解释请求被拒绝原因的任何文件
请求标头：If-Match If-None-Match, If-Unmodified-Since
响应标头：ETag Last-Modified

表示客户端在条件请求中指定的前提条件在服务器端不满足。用于乐观锁定。
示例： If-Unmodified-Since：如果在请求的 If-Unmodified-Since: 标头中写入的时间之后有更新，则返回。

一个常见的前提条件是 If-Unmodified-Since。客户端发送（PUT）更改资源的请求，但仅在自客户端上次获取资源后没有其他客户端更改资源时才应用更改。不指定前提条件可能导致客户端在不知不觉中覆盖其他客户端所做的更改，导致 409（冲突）。

客户端可以使用 If-Match、If-None-Match 或 If-Unmodified-Since 标头获取此响应代码。
If-None-Match 有点特别。如果客户端在发送 GET 或 HEAD 请求时指定了 If-None-Match 且不满足前置条件，则响应码为 304（未修改）而不是 412。它基于条件 HTTP GET。如果 PUT POST DELETE 请求指定 If-None-Match 且不满足前置条件，则响应码为 412。如果您使用 If-Match 或 If -Unmodified-Since 标头作为前提条件，则无论 HTTP 方法如何，响应代码都是 412。

◎ 标头 If-Match

类型：请求头
严重性：中
相关 HTTP 方法：PUT / DELETE
值：ETag

表示如果与提供的 ETag 匹配，则执行请求。

最好通过将其与其他标题进行比较来解释此标题。类似于 If -Unmodified-Since（如下所述），此标头用于执行除条件 GET 之外的 HTTP 操作。但是如果 - Unmodified-Since 将时间作为它的值
, 这个头有一个 ETag 作为它的值。简单地说，这个头是对 If-None-Match 和 ETag what If Unmodified-Since 是对 If -Modified-Since 和 Last Modified。

◎ Header If-None-Match

类型：请求头
严重性：非常高
相关HTTP方法：GET
值：ETag

表示当呈现的 ETag 不匹配时将获取资源。

此标头也用于条件 HTTP GET。它的值是 ETag 响应标头的值，从先前对该 URI 的请求中获得。如果自上次请求以来 ETag 已更改，则满足 If -None-Match 条件并且服务器发送新的实体主体。如果ETag与上次相同，则不满足条件，服务器发送响应码304（未修改），不发送entity-body。

◎ Header If-Modified-Since

类型：请求头
严重性：非常高
相关HTTP方法：GET
值：日期时间

指示如果当前源已在显示的日期和时间之后更新，则将获取资源。

此请求标头是条件 HTTP GET 的核心。它的值是 Last-Modified 响应标头的先前值，从先前对该 URI 的请求获得。如果自上次请求以来资源已更改，则新的 Last-Modified 日期将更新。这意味着满足 If-Modified-Since 条件并且服务器发送一个新的实体主体。如果资源未更改，则 Last-Modified 日期保持不变并且不满足 If Modified-Since 条件。服务器发送响应代码 304（未修改）并且不发送实体主体。换句话说，如果不满足此条件，则有条件的 HTTP GET 成功。
Last Modified 精确到一秒钟，因此仅依赖 If-Modified-Since 的条件 HTTP GET 可能会给出不正确的结果。这就是为什么我们还使用 ETag 和 If-None-Match 的主要原因。

◎ Header Last-Modified

类型：响应头
严重性：非常高
值：日期时间

此标头告诉客户端上次更改表示的时间。客户端可以管理这个日期和时间，并在后续请求的 If Modified-Since 标头中使用它。

在 Web 应用程序中，Last Modified 通常是当前时间，因此有条件的 HTTP GET 是没有用的。 Web 服务客户端通常可以使用对相同 URI 的请求来围攻服务器，因此 Web 服务应该做得更好一些。

❐ 415 不支持的媒体类型“不支持的媒体类型”

严重性：中
相关 HTTP 方法：PUT / POST
正文：解释请求被拒绝原因的任何文件
请求标头：内容类型

服务器不支持客户端指定的媒体类型
表示比如Image Registration Web API，比如服务器支持的图片。
当客户端尝试注册 GIF 格式的图像时使用它，即使图像格式只有 JPEG 和 PNG，或者当客户端发送 JSON，即使服务器需要 XML。

当客户端发送具有正确媒体类型但格式错误的文档（例如用错误词汇表编写的 XML 文档）时，更通用的响应代码 400（错误请求）更合适。

◎ Header Content-Type

类型：请求和响应标头
严重性：非常高
值：媒体类型

可以说是最著名的响应标头。此标头告诉客户端它是哪种实体主体。在传统的 Web 中，Web 浏览器使用此标头来确定实体主体是否可以内联呈现，如果不能，则应该运行什么外部程序。在可编程 Web 中，Web 服务客户端通常使用此标头来确定将哪个解析器应用于实体主体。 Content-Type 还用于请求标头中，以标识 Web 服务客户端发送到服务器的表示类型。

❐418我是茶壶

我是一个茶壶HTCPCP/1.0 的扩展状态码。
如果茶壶拒绝煮咖啡，则应该返回一个笑话代码。 2017 年有一项将其删除的运动，但由于抗议，418 现在正式从 RFC 9110 中“保留”。

4-4. 5xx：服务器错误响应

表示客户端出现问题。身份验证、表示格式或 HTTP 库本身的问题。您必须在客户端解决问题。

服务器处理请求失败

5xx 系列状态码用于表示服务器端问题。大多数时候，这些代码意味着服务器甚至没有处于完成客户端请求的状态，甚至没有验证请求是否正确，客户端应该稍后重新发送请求。服务器可以估计客户端应该在多长时间后重新发送请求，并在 Retry After 响应标头中设置该信息。

5xx 状态码比 4xx 状态码少，不是因为服务器上发生的错误更少，而是因为明确指出这些错误没有多大意义。客户端无法做任何事情来解决服务器上的问题。

❐ 500 内部服务器错误

严重性：高
相关 HTTP 方法：全部
正文：解释请求被拒绝原因的任何文件

表示发生了一些服务器不知道如何处理的事情。
这是一个通用的服务器错误响应。大多数 Web 框架在执行引发异常的请求处理程序代码时都会发送此状态代码。

例如，当以 CGI 方式运行的程序出现语法错误，或者设置有错误时返回。

❐ 503 服务不可用

严重性：中到高
相关 HTTP 方法：全部
正文：解释请求被拒绝原因的任何文件
响应标头：重试后

此状态码表示 HTTP 服务器正在运行，但 Web 服务无法正常工作。在大多数情况下，原因是缺乏资源。表示一次收到的请求太多，服务无法全部处理。

由于重复的客户端请求可能是问题的原因，HTTP 服务器可以选择简单地拒绝接受客户端请求，而不是仅仅发送 503 响应代码。
服务器可能会发送 Retry After 标头以向客户端指示何时可以恢复发送请求。

5.其他常用的HTTP Headers

◎ 用户代理

类型：请求标头
严重性：高
值：客户端软件名称和版本

此标头允许服务器了解正在发送 HTTP 请求的软件类型。

几乎所有现代浏览器都伪装成 Mozilla。它是第一个流行的 Web 浏览器（Netscape Navigator）的内部代号。不伪装成 Mozilla 的浏览器可能无法获得您想要的表示。一些浏览器伪装成 Mozilla 和 MSIE，以便它们可以调用 Internet Explorer 的代码。

Web 服务应该只使用 User-Agents 来收集统计信息并拒绝对编程不佳的客户端的访问。 User-Agent 不应用于为特定客户定制演示文稿。

◎ 主持人

类型：请求标头
严重性：必填
值：主机名和端口号

此标头包含 URI 的域名部分。客户端http://www.example.com/page.html，URI 路径为“/page.html”，Host 标头的值为“www.example.com”或“www.example.com:80”。

从客户端的角度来看，这是一个必需的标头可能看起来很奇怪。之所以需要此标头是因为 HTTP 1.1 服务器可以在单个 IP 地址上托管任意数量的域。

此功能称为“基于名称的虚拟主机”，如果您拥有多个域，则无需为每个域购买单独的计算机和网卡。问题在于 HTTP 客户端将请求发送到 IP 地址而不是域名。如果没有 Host 标头，服务器将不知道客户端请求的目标是哪个虚拟主机。

◎ Header Content-Length

类型：请求/响应标头
严重性：高
值：十进制值（字节）

此响应标头指示正文的大小（以字节为单位）。这个值很重要，有两个原因。

首先，客户可以读取该值并为小型或大型机构做准备。然后，客户端可以发送 HEAD 请求以找出主体的大小，而无需实际请求实体主体。

Content-Length 的值可以影响客户端获取整个正文、 Range 中的一部分或根本不获取的决定。

◎ 标题 Cookie

类型：请求标头
重要性：经典 Web 高，可编程 Web 低
值：字符串

可能是仅次于 Content-Type 的第二个最著名的 HTTP 标头，但未包含在 HTTP 规范中。此标头是 Netscape 扩展。

cookie 是客户端和服务器之间的协议，服务器使用 Set Cookie 头在客户端存储半持久状态。通过为每个 cookie 设置一次 Cookie 标头，期望获取 cookie 的客户端将所有后续 HTTP 请求返回到服务器的 cookie。由于每个请求都隐藏在 HTTP 标头中发送数据，这就像客户端和服务器共享状态。

Cookie 在 REST 世界中名声不好，原因有两个。首先，cookie 中包含的“状态”通常只是一个会话 ID（即，与服务器上更大的数据结构相关联的简短字母数字键）。这违背了无国籍原则。更巧妙的是，接收到 cookie 的客户端将在一段时间内针对每个请求发送 cookie。服务器告诉客户端它在获得 cookie 之前不能再发送请求。这也违反了无国籍原则。

如果必须使用 cookie，请尝试将所有状态存储在客户端。否则，您将失去 REST 的大部分可扩展性优势。

◎ Header Set-Cookie

类型：响应头
重要性：经典 Web 高，可编程 Web 低
值：字符串

它用于设置从服务器到客户端的会话信息等。

尝试在服务器端的客户端 cookie 中设置一些半持久状态。客户端在所有后续请求中发送适当的 cookie 标头，直到 cookie 过期。有时客户端会忽略此标头（在传统 Web 中这通常是一件好事），但后续请求将得到良好的响应，除非它们提供 Cookie 标头。没有保证。这违背了无国籍原则。

层	姓名	标准（协议）	主要使用示例	在电脑上处理
4层	应用层	HTTP、HTTPS、SMTP、POP3、 IMAP4、DHCP、DNS SSH、SMTP 等	网页浏览、电子邮件、文件传输、名称解析等。	通讯应用程序
3层	传输层	TCP、UDP、NetWare/IP 等	TCP/UDP通讯方式选择（将数据分发到适当的应用程序）	操作系统
2层	互联网层	IP、ARP、RARP、ICMP等	路由，端到端通信使用 IPv4 或 IPv6 连接	操作系统
1层	网络接口层	以太网	局域网如 MAC 地址和以太网物理电缆等通信方式	设备、驱动程序、网卡

	TCP	UDP
通讯方式	连接类型	数据图类型
特征	强调确定性	强调即时性
可靠性	高	低的
使用速度	低速	高速
使用示例	网页浏览、电子邮件等一般如何使用互联网	IP电话、视频分发、网络会议等如何强调实时性

原创声明：本文系作者授权爱码网发表，未经许可，不得转载;

原文地址：https://www.likecs.com/show-308632238.html

首先

一、HTTP/TCP/IP/REST基础

1-1. REST (REpresentational State Transfer) 的四个原则

1-2. 万物皆有的抽象 〇〇

1-3. 什么是资源？

1-4. URI、URL 和 URN

1-5. 什么是 TCP/IP

1-5-1. 分层协议

1-5-2. 网络接口层

1-5-3. 互联网层

1-5-4. 传输层

1-5-5. 应用层

1- 6. HTTP 方法（GET/POST/PUT/DELETE）

1-6-1. GET -> 获取资源

1-6-2. POST -> 创建和添加资源

1-6-3. PUT -> 更新，创建资源

1-6-4. 删除 -> 删除资源

2.什么是HTTP响应状态码？

2-1. HTTP响应大致分为三种

2-1-1. HTTP 响应码

2-1-2. 响应头

2-1-3. 身体

3. HTTP响应代码概述

3-1. 最少需要 3~7 个代码

❐ 200（确定）

❐ 400（错误请求）

❐ 500（内部服务器错误）

❐ 301（永久移动）

❐ 404（未找到）和 410（已消失）

❐ 409（冲突）

4.HTTP响应码详情

4-1. 1xx：信息响应（处理）

❐ 100 继续

◎ 标题期望

4-2. 2xx：响应成功

❐ 200 确定“确定”

❐ 201 已创建

◎ 标题位置

❐ 202 已接受

◎ Header Retry-After

❐ 204 无内容

❐ 206 部分内容

◎ 范围标头

◎ 标题内容-范围

4-3. 3xx：重定向消息

❐ 301 永久移动

❐ 302 找到“发现”

❐ 303 查看其他

❐ 304 未修改

◎ 标题日期

◎ 标头ETag

◎ Header Cache-Control

◎ 标头过期

❐ 307 临时重定向

❐ 308 永久重定向

4-4. 4xx：客户端错误响应

❐ 400 错误请求“请求无效”

❐ 401 未经授权的“需要身份验证”

◎ 头部授权

◎ Header WWW-Authenticate

❐ 403 禁止“禁止”

❐ 404 未找到

❐ 405 方法不允许“方法不允许”

◎ 标题允许

❐ 406 不可接受

◎ 标头接受

◎ Header Accept-Encoding

❐ 409 冲突

❐ 410 Gone“消失”

❐ 412 前提条件失败

◎ 标头 If-Match

◎ Header If-None-Match

◎ Header If-Modified-Since

◎ Header Last-Modified

❐ 415 不支持的媒体类型“不支持的媒体类型”

◎ Header Content-Type

❐418我是茶壶

4-4. 5xx：服务器错误响应

❐ 500 内部服务器错误

❐ 503 服务不可用

1-2. 万物皆有的抽象〇〇