URL 的语法
<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>
| 组件 | 描述 | 默认值 |
|---|---|---|
| 方案 | 访问服务器以获取资源时需要使用哪种协议 | 无 |
| 用户 | 某些方案访问资源时需要的用户名 | 匿名 |
| 密码 | 用户名后面可能要包含的密码，中间由冒号分隔 | <E-mail 地址> |
| 主机 | 资源宿主服务器的主机名或点分IP地址 | 无 |
| 端口 | 资源宿主服务器正在监听的端口号。很多方案都有默认端口号。 | 每个方案特有 |
| 路径 | 服务器上资源的本地名，由一个斜杠/将其与前面的URL组件分隔开来。路径组件的语法是与服务器和方案有关的。 |
无 |
| 参数 | 某些方案会用这个组件来指定输入参数。参数为名/值对。URL中可以包含多个参数字段，它们相互之间以及与路径的其余部分之间用分号;分隔 |
无 |
| 查询 | 某些方案会用这个组件传递参数以激活应用程序。查询组件的内容没有通用格式。用字符?将其与URL的其余部分分隔开来。 |
|
| 片段 | 一小片或一部分资源的名字。引用对象时，不会将frag字段传送给服务器；这个字段是在客户端内部使用的。通过字符#将其与URL的其余部分分隔开来。 |
无 |
报文的语法
请求报文
<method> <request-URL> <version>
<headers>
<entity-body>
POST /api/sign/register.json HTTP/1.1
Host: dev.zhiaotech.com:8005
Content-Length: 13
Accept: */*
Origin: http://dev.zhiaotech.com:8004
DNT: 1
Content-Type: application/json
Connection: keep-alive
{"name":"xx"}
响应报文
<version> <status-code> <reason-phrase>
<headers>
<entity-body>
HTTP/1.1 200 OK
Server: nginx/1.10.3 (Ubuntu)
Content-Type: application/json
Transfer-Encoding: chunked
Access-Control-Allow-Origin: http://dev.zhiaotech.com:8004
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Origin, Content-Type, Cookie, Accept
Access-Control-Allow-Methods: GET, POST, PATCH, PUT, OPTIONS
Cache-Control: no-cache, private
Date: Wed, 27 Feb 2019 00:20:44 GMT
Set-Cookie: laravel_session=4Q8jPlqCd0Ex9GOa8Nujblgaun8sNs;
expires=Wed, 27-Feb-2019 02:20:44 GMT; Max-Age=7200; path=/; httponly
Proxy-Connection: keep-alive
{"data":"","code":1001,"msg":"未登录"}
-
方法（method）
客户端希望服务器对资源执行的动作。是一个单独的词，比如GET、HEAD、或POST等等。
-
请求URL（request-URL）
命名了所请求资源，或者URL路径组件的完整URL。
-
版本（version）
报文所使用的 HTTP 版本，其格式看起来是这样的：
HTTP/<major>.<minor>
其中major和minor都是整数 -
状态码（status-code）
为三位数字，这三位数字描述了请求过程中所发生的情况。每个状态码的第一位数字都用于描述状态的一般类别（“成功”、“出错”等）。
-
原因短语（reason-phrase）
数字状态码的可读版本，包含行终止序列之前的所有文本。原因短语只对人类有意义。
-
首部（header）
可以有零个或多个首部，每个首部都包含一个名字，后面跟着一个冒号
:，然后是一个可选的空格，接着是一个值，最后是一个CRLF。首部是由一个空行CRLF结束的，表示了首部列表的结束和实体主体部分的开始。有些HTTP版本，比如HTTP/1.1，要求有效的请求或相应报文中必须包含特定的首部。 -
实体的主体部分（entity-body）
实体的主体部分包含一个由任意数据组成的数据块。并不是所有的报文都包含实体的主题部分，有时，报文只是以一个
CRLF结束。
起始行
请求行
包含了一个方法和一个请求URL，请求行中还包含HTTP的版本，在HTTP/1.0之前，并不要求请求行中包含HTTP版本号。
响应行
包含HTTP版本，数字状态码，以及描述操作状态的文本形式的原因短语。
方法
常用的HTTP方法有以下7种，注意，有些方法的请求报文中有主体，有的则没有。
| 方法 | 描述 | 是否包含主体 |
|---|---|---|
| GET | 从服务器获取一份文档 | 否 |
| HEAD | 只从服务器获取文档的首部 | 否 |
| POST | 向服务器发送需要处理的数据 | 是 |
| PUT | 将请求的主体部分存储在服务器上 | 是 |
| TRACE | 对可能经过代理服务器传送到服务器上去的报文进行追踪 | 否 |
| OPTIONS | 决定可以在服务器上执行哪些方法 | 否 |
| DELETE | 从服务器上删除一份文档 | 否 |
状态码
通过三位数字代码对不同状态码进行分类，200到299之间的状态码表示成功。300到399之间的代码表示资源已经被移走了。400到499之间的代码表示客户端的请求出错了。500到599之间的代码表示服务器出错了。
| 整体范围 | 已定义范围 | 分类 |
|---|---|---|
| 100 ~199 | 100 ~ 101 | 信息提示 |
| 200 ~ 299 | 200 ~ 206 | 成功 |
| 300 ~ 399 | 300 ~ 305 | 重定向 |
| 400 ~ 499 | 400 ~ 415 | 客户端错误 |
| 500 ~ 599 | 500 ~ 505 | 服务端错误 |
原因短语
原因短语和状态码是成对出现的。原因短语是状态码的可读版本，应用程序开发者将其传送给用户，用以说明在请求期间发生了什么情况。
HTTP规范并没有提供任何硬性规定，要求原因短语以何种形式出现。
首部
首部分类
HTTP规范定义了几种首部字段。应用程序也可以随意发明自己所用的首部。HTTP首部可以分为以下几类。
-
通用首部
既可以出现在请求报文中，也可以出现在响应报文中。
-
请求首部
提供更多有关请求的信息。
-
响应首部
提供更多有关响应的信息。
-
实体首部
描述主题的长度和内容，或者资源自身。
-
扩展首部
规范中没有定义的新首部。
常见的首部实例
| 首部实例 | 描述 |
|---|---|
| Date:Tue,3Oct 1997 02:16:03 GMT | 服务器产生响应的日期 |
| Content-Length:15040 | 实体的主体部分包含了15040字节的数据 |
| Content-Type:image/gif | 实体的主体部分是一个GIF图片 |
| Accept:image/gif, image/jpeg, text/html | 客户端可以接受GIF图片和JPEG图片以及HTML |
首部延续行
将长的首部行分为多行可以提高可读性，多出来的每行前面至少要有一个空格或制表符（tab）
例如：
HTTP/1.0 200 OK
Content-Type: image/gif
Content-Length: 8572
Server: Test Server
Version 1.0
在这个例子中，Server 首部的值 Test Server Version 1.0 被划分成了多个延续行。
