HTTP协议

HTTP协议描述

HTTP协议是Hyper Text Transfer Protocol（超文本传输协议）的缩写,是用于从万维网（WWW:World Wide Web ）服务器传输超文本^[1]到本地浏览器的传送协议。HTTP是一个基于TCP/IP通信协议来传递数据（HTML 文件, 图片文件, 查询结果等）。

通常，由HTTP客户端发起一个请求，建立一个到服务器指定端口（默认是80端口）的TCP连接。HTTP服务器则在那个端口监听客户端发送过来的请求。一旦收到请求，服务器（向客户端）发回一个状态行，比如"HTTP/1.1 200 OK"，和（响应的）消息，消息的消息体可能是请求的文件、错误消息、或者其它一些信息。

HTTP是一个客户端和服务器端请求和应答的标准（TCP）。客户端是终端用户，服务器端是网站。通过使用Web浏览器、网络爬虫或者其它工具的客户端发起一个到服务器上指定端口（默认端口为80）的HTTP请求，称这个客户端叫用户代理（user agent）。

在Internet中所有的传输都是通过TCP/IP进行的。HTTP协议作为TCP/IP模型中应用层的协议也不例外。HTTP协议通常承载于TCP协议之上，有时也承载于TLS或SSL协议层之上，这个时候，就成了我们常说的HTTPS。
<center>

15215564008151.jpg -w400

</center>

HTTP默认的端口号为80，HTTPS的端口号为443。

浏览网页是HTTP的主要应用，但是这并不代表HTTP就只能应用于网页的浏览。HTTP是一种协议，只要通信的双方都遵守这个协议，HTTP就能有用武之地。

HTTP特点

1. 无状态：每次HTTP请求都是独立的，任何两个请求之间没有什么必然的联系。

   协议的状态是指下一次传输可以“记住”这次传输信息的能力。HTTP是不会为了下一次连接而维护这次连接所传输的信息,为了保证服务器内存。

2. 支持客户/服务器模式。支持基本认证和安全认证。

3. 简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。

4. 灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。

5. HTTP 0.9和1.0使用非持续连接：限制每次连接只处理一个请求，服务器处理完客户的请求，并收到客户的应答后，即断开连接。HTTP 1.1使用持续连接：不必为每个web对象创建一个新的连接，一个连接可以传送多个对象，采用这种方式可以节省传输时间。

HTTP工作流程

一次HTTP操作称为一个事务，其工作过程可分为四步：

1. 首先客户机与服务器需要建立连接。只要单击某个超级链接，HTTP的工作开始。
2. 建立连接后，客户机发送一个请求给服务器，请求方式的格式为：统一资源标识符（URL）、协议版本号，后边是MIME信息包括请求修饰符、客户机信息和可能的内容。
3. 服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是MIME信息包括服务器信息、实体信息和可能的内容。
4. 客户端接收服务器所返回的信息通过浏览器显示在用户的显示屏上，然后客户机与服务器断开连接。

URI

URI（统一资源标识符）^[2]：是一个用于标识某一互联网资源名称的字符串。而这个资源由两个部分确定：资源地址信息（URL）+资源名称信息（URN）;

常见的URI格式如下：
http://user:password@host.com:8080/p/a/t/h?query=string&action=add#has

HTTP请求与响应

HTTP协议分为请求（Request）与响应（Response）两个部分。

Request——请求

请求内容

请求信息内容包括以下几点：

• 请求行——request line

  • 请求方法：GET/POST/HEAD/DELETE/PUT/TRACE/OPTIONS。方法名称是区分大小写的。当某个请求所针对的资源不支持对应的请求方法的时候，服务器应当返回状态码405（Method Not Allowed）；当服务器不认识或者不支持对应的请求方法的时候，应当返回状态码501（Not Implemented）。HTTP服务器至少应该实现GET和HEAD方法，其他方法都是可选的。此外，除了上述方法，特定的HTTP服务器还能够扩展自定义的方法。

    请求方法	含义
    OPTIONS	返回服务器针对特定资源所支持的HTTP请求方法。也可以利用向Web服务器发送'*'的请求来测试服务器的功能性。
    HEAD	向服务器索要与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以在不必传输整个响应内容的情况下，就可以获取包含在响应消息头中的元信息。该方法常用于测试超链接的有效性，是否可以访问，以及最近是否更新。
    GET	向特定的资源发出请求。注意：GET方法不应当被用于产生“副作用”的操作中，例如在web app中。其中一个原因是GET可能会被网络蜘蛛等随意访问。
    POST	向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
    PUT	向指定资源位置上传其最新内容。
    DELETE	请求服务器删除Request-URI所标识的资源。
    TRACE	回显服务器收到的请求，主要用于测试或诊断。
    CONNECT	HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
    PATCH	用来将局部修改应用于某一资源，添加于规范RFC5789。

  • 请求资源虚拟路径

  • 请求协议

• 请求头信息——header

  • POST请求头是需要追那个请求主体的长度；如果不注明长度则不会发送请求主体信息；

    content-length:length # length为非零整型数据
    

  • 服务器要想能够解析道POST数据还需要请求头包含数据类型

    content-length:appliacation/x-www-from-urlencoded #数据编码格式
    

  • 格式为key=>value键值对的形式

• 空行
• 请求主体信息
  • 使用“&”拼接在一起的key=>value键值对。

【注意】
请求头信息与请求主体信息之间要有一个空行！

请求格式

METHOD /path-to-resource HTTP/Version-number
Header-name-1:Value
Header-name-2:Value

Optional request body

示例

# GET 请求
GET /generate_204 HTTP/1.1 //请求方法 请求虚拟路径 请求协议——请求行
User-Agent: Dalvik/2.1.0 (Linux; U; Android 7.0; MI 5 MIUI/V9.5.1.0.NAACNFA)    //请求头
Host: connect.rom.miui.com  //主机——请求头
Connection: Keep-Alive  //请求头
Accept-Encoding: gzip   //请求头

# POST 请求
POST /quickService/ajax/getServiceCategory.ajax.php HTTP/1.1    //请求行
Host: api1.yaxinzhichuang.com   //请求头
Content-Length: 26  //请求头
Pragma: no-cache
Cache-Control: no-cache
Accept: application/json
Origin: http://api1.yaxinzhichuang.com
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Linux; Android 7.0; MI 5 Build/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/62.0.3202.84 Mobile Safari/537.36
Content-Type: application/x-www-form-urlencoded
Referer: http://api1.yaxinzhichuang.com/quickService/index.php?action=quickService
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,en-US;q=0.9
Cookie: PHPSESSID=497cde80b0d132a375e872bae9668c41
    // 空行
action=children&parentId=2  //  请求主体信息

Response——响应

响应内容

响应信息内容包括以下几点：

• 响应行
  • 由HTTP协议版本号
  • 状态码
  • 状态文字
• 响应头信息
  • 格式为key=>value键值对的形式
• 空行
• 响应主体信息（也可能没有）

响应格式

HTTP/Version-number status-code message 
Header-name-1:Value
Header-name-2:Value

Optional response body

示例

## json响应
HTTP/1.1 200 OK     //  响应行
Date: Tue, 20 Mar 2018 16:11:59 GMT //响应行
Server: Apache/2.2.34 (Unix)    //响应行
Expires: Thu, 19 Nov 1981 08:52:00 GMT  //响应行
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0   //响应行
Pragma: no-cache    //响应行
Content-Length: 146 //响应行
Content-Type: text/json;charset=utf-8   //响应行
Proxy-Connection: Keep-alive    //响应行
    //空行
{"Code":100000,"Msg":"操作成功！","Data":{"List":[{"value":"7","text":"电脑系统服务"},{"value":"45","text":"维修"}],"uploadImg":"1"}}    ////响应主体信息，可能是html页面；

API

定义

一些预先定义的函数，目的是能够让应用程序或开发人员能够具有访问指定网络资源的能力，而无需关心访问的远吗以及内部的工作机制细节。

RESTful

为了统一API结构设计规范提出的一种架构标准；然而，RESTful并不是唯一的API架构标准。
REST是“REpresentational State Transfer”的缩写；表现性状态转换；

概念

在RESTful架构中认为所有一切都是资源，每个资源有对应的URI^[2]标识；
处理资源的操作有：

客户端通过以上4种http动词，对服务器资源进行操作，实现“表现层状态转化”；

【注意】
只是一种架构而不是标准，提供设计原则和约束条件。
适用于客户端与服务器交互类的软件，这是因为它更加简洁、有层次、更利于实现缓存等机制；

规范

协议

REST API与客户端通信协议为http协议；

域名

应该尽量将API放在专属于名下。

http://api.example.com

版本

应该将API的版本好放入URL中。

http://api.example.com/version/

路径

表示API的具体网址，在RESTful架构中，每个网址代表了一种资源，所以网址中不能有动词，只能有名词，故API中的名词应该用复数形式。

http动词

对http资源的具体操作类型，有http动词表示。

过滤信息

过滤信息可以理解为query string即：?limit=10&page=1&id=12；为API提供参数，过滤并返回结果。

状态码

服务器向用户返回的状态吗和提示信息，常见的有以下部分：

• 2XX：这一类型的状态码，代表请求已成功被服务器接收、理解、并接受。
• 3xx重定向：这类状态码代表需要客户端采取进一步的操作才能完成请求。通常，这些状态码用来重定向，后续的请求地址（重定向目标）在本次响应的Location域中指明。当且仅当后续的请求所使用的方法是GET或者HEAD时，用户浏览器才可以在没有用户介入的情况下自动提交所需要的后续请求。客户端应当自动监测无限循环重定向（例如：A→B→C→……→A或A→A），因为这会导致服务器和客户端大量不必要的资源消耗。按照HTTP/1.0版规范的建议，浏览器不应自动访问超过5次的重定向。
• 4xx客户端错误：这类的状态码代表了客户端看起来可能发生了错误，妨碍了服务器的处理。除非响应的是一个HEAD请求，否则服务器就应该返回一个解释当前错误状况的实体，以及这是临时的还是永久性的状况。这些状态码适用于任何请求方法。浏览器应当向用户显示任何包含在此类错误响应中的实体内容。
• 5xx服务器错误：表示服务器无法完成明显有效的请求。这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生，也有可能是服务器意识到以当前的软硬件资源无法完成对请求的处理。除非这是一个HEAD请求，否则服务器应当包含一个解释当前错误状态以及这个状况是临时的还是永久的解释信息实体。浏览器应当向用户展示任何在当前响应中被包含的实体。这些状态码适用于任何响应方法。

关于状态码详情参见“维基百科揭秘——HTTP状态码”；

错误信息

如果产生错误，就应该向用户返回出错信息。返回信息中将error作为建明，出错信息作为键值即可。

{
    "error":"Invalid API Key!"
}

返回结果

针对不同操作，服务器向用户返回的结果应该符合以下规范。

GET /collection: 返回资源对象列表
GET /collection/resource:返回单个资源对象
POST /collection:返回新创建的资源对象
PUT /collection:返回完整的资源对象
PATCh /collection:返回完整的资源对象
DELETE /collection:返回一个空文档

RESTful不规范使用

接口中添加GET/UPDATE等动词

在URI中添加操作名称；而是应该通过http动词表示请求资源的操作动作，如：GET/UPDATE，来表示接口的含义；

//不规范使用方法
GET /getUser
POST /updateUser
POST /cowfarm/cowfarmemp/new
POST /cowfarm/cowfarmemp/update
POST /cowfarm/cowfarmemp/delete/{id}

//正确使用方法
GET /user               # 获取一个用户的信息；
PUT /user               # 更新用户的信息；
POST /cowfarm/employee  # 表示 新建一个农场的雇员/员工；
PUT /cowfarm/employee   # 表示 更新农场雇员/员工的信息；
DELETE /cowfarm/employee# body中包含json参数，表示删除用户，且返回值中，message，code应该正常返回，data就没必要返回了

非改动资源的操作却设计为POST/PUT等方法

对于没有新增/更新/删除等去改动和影响资源的操作，HTTP的方法却设计为POST/PUT等

RESTful API返回数据的格式

常用数据返回格式为json格式，或者使用比较少的XML。

1. 超文本：超文本系统是一种提供了复杂格式的解释的软件系统，包括文本，图像，超链接一种文字间的跳转以提供某一个关键词的相关内容。 ↩

2. URI：统一资源标识符（英语：Uniform Resource Identifier，或URI）是一个用于标识某一互联网资源名称的字符串。可以这么理解URI=URL+URN；URL(定位符——资源地址)和URN(名称——资源名称)方案属于URI的子类，URI可以为URL或URN两者之一或同时是URI和URN。技术上讲，URL和URN属于资源ID；但是，人们往往无法将某种方案归类于两者中的某一个：所有的URI都可被作为名称看待，而某些方案同时体现了两者中的不同部分。 ↩ ↩