HTTP协议是建立在TCP之上的无状态应用层协议，用于收发网络资源（通常是HTML页面），默认使用80端口。
HTTP协议是以 ASCII码传输，建立在 TCP/IP协议之上的应用层规范。规范把 HTTP请求分为三个部分：状态行、请求头、消息主体。类似于下面这样：
GET可提交的数据量受到URL长度的，HTTP协议规范没有对 URL长度进行。这个是特定的浏览器及服务器对它的 -理论上讲，POST是没有大小的，HTTP协议规范也没有进行大小，出于安全考虑，服务器软件在实现时会做一定
参考的报文示例，可以发现 GET和 POST数据内容是一模一样的，只是不同，一个在URL里，一个在 HTTP包的包体里
GET方法访问的地址通常复制到浏览器地址栏，可以直接访问结果，而POST方法必须借助工具（如 POSTman或者 CURL命令等）来进行访问。
这是最常见的 POST数据提交方式。浏览器的原生 `form`表单，如果不设置 enctype属性，那么最终就会以 `application/x-www-form-urlencoded`方式提交数据。上个小节当中的例子便是使用了这种提交方式。可以看到 body当中的内容和 GET请求是完全相同的。
这个例子稍微复杂点。首先生成了一个 boundary用于分割不同的字段，为了避免与正文内容重复，boundary很长很复杂。然后 `Content-Type`里指明了数据是以 `multipart/form-data`来编码，本次请求的 boundary是什么内容。消息主体里按照字段个数又分为多个结构类似的部分，每部分都是以 --boundary开始，紧接着是内容描述信息，然后是回车，最后是字段具体内容（文本或二进制）。如果传输的是文件，还要包含文件名和文件类型信息。消息主体最后以 --boundary--标示结束。关于 `multipart/form-data`的详细定义，请前往 [RFC1867](t)查看（或者相对友好一点的 [MDN文档](Content-Disposition)）。
RESTful API随着开发技术的发展，越来越多的复杂功能被放置到了网站上，网站可以被理解为下载到浏览器里执行的软件，而这个网站与后端系统有频繁和复杂的通信；同时，随着移动互联网的兴起，开发人员倾向于APP和网站使用统一的通信接口，从而减小开发和的工作量。RESTful架构即是目前最流行的一种互联网软件架构。它结构清晰、符合标准、易于理解、扩展方便，正得到越来越多网站的采用。（REST是 Representational State Transfer的缩写）1.资源（Resources）
REST的名称表现层状态中，省略了主语。表现层其实指的是资源（Resources）的表现层。
所谓资源，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。你可以用一个URI（统一资源定位符）指向它，每种资源对应一个特定的URI。要获取这个资源，访问它的URI就可以，因此URI就成了每一个资源的地址或独一无二的识别符。
资源是一种信息实体，它可以有多种外在表现形式。我们把资源具体呈现出来的形式，叫做它的表现层（Representation）。
比如，文本可以用txt格式表现，也可以用HTML格式、XML格式、JSON格式表现，甚至可以采用二进制格式；图片可以用JPG格式表现，也可以用PNG格式表现。
URI只代表资源的实体，不代表它的形式。严格地说，有些网址最后的.html后缀名是不必要的，因为这个后缀名表示格式，属于表现层范畴，而URI应该只代表资源的。它的具体表现形式，应该在HTTP请求的头信息中用Accept和Content-Type字段指定，这两个字段才是对表现层的描述。
访问一个网站，就代表了客户端和服务器的一个互动过程。在这个过程中，势必涉及到数据和状态的变化。
互联网通信协议HTTP协议，是一个无状态协议。这意味着，所有的状态都保存在服务器端。因此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生状态（State Transfer）。而这种是建立在表现层之上的，所以就是表现层状态。
客户端用到的手段，只能是HTTP协议。具体来说，就是HTTP协议里面，四个表示操作方式的动词：GET、POST、PUT、DELETE。它们分别对应四种基本操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。
JSON(JavaScript Object Notation)是一种轻量级的数据交换格式。易于人阅读和编写。同时也易于机器解析和生成。在API的设计中使用尤为广泛。JSON建构于两种结构：“名称/值”对的集合（A collection of name/value pairs）。不同的语言中，它被理解为对象（object），纪录（record），结构（struct），字典（dictionary），哈希表（hash table），有键列表（keyed list），或者关联数组 （associative array）。值的有序列表（An ordered list of values）。在大部分语言中，它被理解为数组（array）。这些都是常见的数据结构。事实上大部分现代计算机语言都以某种形式支持它们。这使得一种数据格式在同样基于这些结构的编程语言之间交换成为可能。如，下面为京东的商品评论API及返回的JSON格式数据。可以直接复制该链接到浏览器地址栏打开，查看结果。
1. URL重写。URL(统一资源定位符)是Web上特定页面的地址，URL重写的技术就是在URL结尾添加一个附加数据以标识该会话,把会话ID通过URL的信息传递过去，以便在服务器端进行识别不同的用户。
2.隐藏表单域。将会话ID添加到HTML表单元素中提交到服务器，此表单元素并不在客户端显示。
客户端可以采用两种方式来保存这个Cookie对象，一种方式是保存在客户端内存中，称为临时Cookie，浏览器关闭后这个Cookie对象将消失。另外一种方式是保存在客户机的磁盘上，称为永久Cookie。以后客户端只要访问该网站，就会将这个Cookie再次发送到服务器上，前提是这个Cookie在有效期内，这样就实现了对客户的。
我们知道 HTTP协议采用“请求-应答”模式，当使用普通模式，即非 Keep-Alive模式时，每个请求/应答客户和服务器都要新建一个连接，完成之后立即断开连接（HTTP协议为无连接的协议）；当使用 Keep-Alive模式（又称持久连接、连接重用）时，Keep-Alive功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了建立或者重新建立连接。在 HTTP 1.0版本中，并没有的标准来 Keep-Alive如何工作，因此实际上它是被附加到 HTTP 1.0协议上，如果客户端浏览器支持 Keep-Alive ，那么就在HTTP请求头中添加一个字段 Connection: Keep-Alive，当服务器收到附带有 Connection: Keep-Alive的请求时，它也会在响应头中添加一个同样的字段来使用 Keep-Alive 。这样一来，客户端和服务器之间的HTTP连接就会被保持，不会断开（超过 Keep-Alive的时间，意外断电等情况除外），当客户端发送另外一个请求时，就使用这条已经建立的连接。在 HTTP 1.1版本中，默认情况下所有连接都被保持，如果加入 Connection: close才关闭。目前大部分浏览器都使用 HTTP 1.1协议，也就是说默认都会发起 Keep-Alive的连接请求了，所以是否能完成一个完整的 Keep-Alive连接就看服务器设置情况。由于 HTTP 1.0没有的 Keep-Alive规范，并且也已经基本被淘汰，以下讨论均是针对 HTTP 1.1标准中的 Keep-Alive展开的。
HTTP是一个无状态协议，这意味着每个请求都是的，Keep-Alive没能改变这个结果。另外，Keep-Alive也不能客户端和服务器之间的连接一定是活跃的，在HTTP1.1版本中也如此。唯一能的就是当连接被关闭时你能得到一个通知，所以不应该让程序依赖于Keep-Alive的保持连接特性，否则会有意想不到的后果。
使用长连接之后，客户端、服务端怎么知道本次传输结束呢？两部分：1.判断传输数据是否达到了Content-Length的大小；2.动态生成的文件没有 Content-Length ，它是分块传输（chunked），这时候就要根据 chunked编码来判断，chunked编码的数据在最后有一个空 chunked块，表明本次传输数据结束，详见[这里](HTTP Keep-Alive模式)。什么是 chunked分块传输呢？下面我们就来介绍。
Transfer-Encoding是一个用来标示 HTTP报文传输格式的头部值。尽管这个取值理论上可以有很多，但是当前的 HTTP规范里实际上之定义了一种传输取值——chunked。
如果一个HTTP消息（请求消息或应答消息）的Transfer-Encoding消息头的值为chunked，那么，消息体由数量未定的块组成，并以最后一个大小为0的块为结束。每一个非空的块都以该块包含数据的字节数（字节数以十六进制表示）开始，跟随一个CRLF （回车及换行），然后是数据本身，最后块CRLF结束。在一些实现中，块大小和CRLF之间填充有白空格（0x20）。最后一块是单行，由块大小（0），一些可选的填充白空格，以及CRLF。最后一块不再包含任何数据，但是可以发送可选的尾部，包括消息头字段。消息最后以CRLF结尾。注意：chunked和 multipart两个名词在意义上有类似的地方，不过在 HTTP协议当中这两个概念则不是一个类别的。multipart是一种 Content-Type，标示 HTTP报文内容的类型，而 chunked是一种传输格式，标示报头将以何种方式进行传输。
HTTP Pipelining（HTTP管线化）默认情况下 HTTP协议中每个传输层连接只能承载一个 HTTP请求和响应，浏览器会在收到上一个请求的响应之后，再发送下一个请求。在使用持久连接的情况下，某个连接上消息的传递类似于`请求1 -响应1 -请求2 -响应2 -请求3 -响应3`。
HTTP /1.1要求服务器端支持管线化，但并不要求服务器端也对响应进行管线化处理，只是要求对于管线化的请求不失败即可
由于提到的服务器端问题，管线化很可能并不会带来大幅度的性能提升，而且很多服务器端和代理程序对管线化的支持并不好，因此现代浏览器如 Chrome和Firefox默认并未管线化支持
更多关于 HTTP Pipelining的知识可以参考这里。HTTPSHTTP协议是传输数据，在客户端和服务器之间截获通信流量即可获取，比如代理服务器或者网关等；同时，对于服务器的，客户端也无法鉴别。为了实现较安全的通信，通常是用HTTPS来。超文本传输安全协议（英语：HypertextTransfer Protocol Secure，缩写：HTTPS，常称为HTTP over TLS，HTTP over SSL或HTTP Secure）是一种网络安全传输协议。在计算机网络上，HTTPS经由超文本传输协议进行通信，但利用SSL/TLS来加密数据包。HTTPS开发的主要目的，是提供对网络服务器的**身份认证**，交换数据的**隐私**与**完整性**。使用了HTTPS的网站，现代浏览器会在地址栏以绿色锁形标记进行提示。如：