HTTP & RESTFUL
———————————–
HTTP
———————————–
http概述
http - “超文本传输协议”, 是互联网运用比较广泛的一种网络协议, 所有的www文件都必须遵守这个标准.
Ted Nelson(提出HTTP构想)组织协调万维网协会和互联网工程工作小组共同合作研究, 最终发布了一系列的RFC, 其中著名的RFC 2616定义了HTTP 1.1.
HTTP协议是用于从WWW服务器传输超文本到本地浏览器的传输协议. 它可以使浏览器更加高效, 使网络传输减少.
HTTP协议（HyperText Transfer Protocol，超文本传输协议）是用于从WWW服务器传输超文本到本地浏览器的传输协议。它可以使浏览器更加高效，使网络传输减少。
协议基础
HTTP协议采用了请求/响应模型. 客户端向服务器发送一个请求，请求头包含请求的方法、URL、协议版本、以及包含请求修饰符、客户信息和内容的类似于MIME的消息结构. 服务器以一个状态行作为响应，响应的内容包括消息协议的版本，成功或者错误编码加上包含服务器信息、实体元信息以及可能的实体内容。
通常HTTP消息包括请求消息和响应消息. 并且消息由一个起始行，一个或者多个头域，一个指示头域结束的空行和可选的消息体组成。HTTP的头域包括通用头，请求头，响应头和实体头四个部分。每个头域由一个域名，冒号（:）和域值三部分组成。域名是大小写无关的，域值前可以添加任何数量的空格符，头域可以被扩展为多行，在每行开始处，使用至少一个空格或制表符。
一些关键名词:
- Connection(连接) => 一个传输层的实际环流，它是建立在两个相互通讯的应用程序之间。
- Message(消息) => HTTP通讯的基本单位，包括一个结构化的八元组序列并通过连接传输。
- Request(请求) => 一个从客户端到服务器的请求信息包括应用于资源的方法、资源的标识符和协议的版本号。
- Response(响应) => 一个从服务器返回的信息包括HTTP协议的版本号、请求的状态(例如“成功”或“没找到”)和文档的MIME类型。
- Resource(资源) => 由URI标识的网络数据对象或服务。
- Entity(实体) => 数据资源或来自服务资源的回映的一种特殊表示方法，它可能被包围在一个请求或响应信息中。
- Client(客户机) => 一个为发送请求目的而建立连接的应用程序。
- UserAgent(用户代理) => 初始化一个请求的客户机。它们是浏览器、编辑器或其它用户工具。
- Server(服务器) => 一个接受连接并对请求返回信息的应用程序。
- Originserver(源服务器) => 是一个给定资源可以在其上驻留或被创建的服务器。
- Proxy(代理) => 一个中间程序，它可以充当一个服务器，也可以充当一个客户机，为其它客户机建立请求。
- Gateway(网关) => 一个作为其它服务器中间媒介的服务器。与代理不同的是，网关接受请求就好象对被请求的资源来说它就是源服务器；发出请求的客户机并没有意识到它在同网关打交道。
- Tunnel(通道) => 是作为两个连接中继的中介程序。一旦激活，通道便被认为不属于HTTP通讯，尽管通道可能是被一个HTTP请求初始化的。
- Cache(缓存) => 反应信息的局域存储。
通用头域
通用头域要求请求和响应消息都支持. 常用通用头域包含Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via.
Cache-Control => 指定请求和响应遵循的缓存机制。
Keep-Alive使客户端到服务器端的连接持续有效, 避免了建立或者重新建立连接.
Date => 表示消息发送的时间
- Pragma => 用来包含实现特定的指令，最常用的是Pragma:no-cache。
举例
// 远程的(主机)ip:port
Remote Address:114.215.241.29:80
// 请求的url
Request URL:http://laravelacademy.org/tags/laravel
// 请求方式
Request Method:GET
// 返回状态码
Status Code:200 OK请求消息
请求报文格式如下：
请求行 － 通用信息头 － 请求头 － 实体头 － 报文主体
请求消息的第一行的格式：
MethodSPRequest-URISPHTTP-VersionCRLF
- Request-URI完成的方法，这个字段是大小写敏感的，包括OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE。
- SP表示空格。
- Request-URI遵循URI格式，在此字段为星号（ * ）时，说明请求并不用于某个特定的资源地址，而是用于服务器本身。
- HTTP-Version表示支持的HTTP版本，例如为HTTP/1.1。
- CRLF表示换行回车符。
请求报文方法及功能:
| 方法名称 | 功能描述 | 是否包含主体数据 |
|---|---|---|
| GET | 从服务器获取文本 | 否 |
| POST | 向服务器发送客户端数据 | 是 |
| PUT | 上传客户端的文件到服务器 | 是 |
| DELETE | 从服务器上删除一个文件 | 否 |
| HEAD | 只获取服务器响应的首部 | 否 |
| OPTIONS | 获取服务器可以执行的方法 | 否 |
| TRACE | 对进过代理服务器的报文进行追踪 | 否 |
举例
Request Headers view source
// 客户端可接收的资源类型
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
// 可接收的编码类型
Accept-Encoding:gzip,deflate,sdch
// 可接收的语言
Accept-Language:zh-CN,zh;q=0.8,en;q=0.6
// 指定缓存机制
Cache-Control:max-age=0
// 指定连接状态
Connection:keep-alive
// 写到客户端的cookie信息
Cookie:3thread-20160919142337=1; niuxamss30=1; CNZZDATA1256294264=1147170700-1474188023-null%7C1474980126; Hm_lvt_0149df826a6be49c34721817692bbf7f=1474783783,1474783875,1474856491,1474985147; Hm_lpvt_0149df826a6be49c34721817692bbf7f=1474985147; _ga=GA1.2.245951336.1474189762; _gat=1
// 主机域名
Host:laravelacademy.org
// 发出请求的客户端(浏览器)信息
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36除了以上内容, 还可能有下面一些内容:
- Referer => 允许客户端指定请求uri的源资源地址，这可以允许服务器生成回退链表，可用来登陆、优化cache等。
- Range => 可以请求实体的一个或者多个子范围。
Cookie
简介
Cookie，有时也用其复数形式Cookies，指某些网站为了辨别用户身份、进行session跟踪而储存在用户本地终端上的数据（通常经过加密）。
因为 Cookie是由 Web服务器保存在用户浏览器上的小文本文件,它包含有关用户的信息, 因而 Cookie的使用对网络用户的隐私构成了危害 。但是网站以外的用户无法跨过网站来获得 Cookie信息。
通常情况下，当用户结束浏览器会话时，系统将终止所有的Cookie。当 Web 服务器创建了Cookies 后，只要在其有效期内，当用户访问同一个 Web 服务器时，浏览器首先要检查本地的Cookies，并将其原样发送给 Web 服务器。
有些 Cookie是临时的 , 有些则是持续的。Cookie在生成时就会被指定一个Expire值，这就是Cookie的生存周期，在这个周期内Cookie有效，超出周期Cookie就会被清除。有些页面将Cookie的生存周期设置为“0”或负值，这样在关闭浏览器时，就马上清除Cookie，不会记录用户信息，更加安全。
Cookies最典型的应用是判定注册用户是否已经登录网站, 另一个重要应用场合是“购物车”之类处理。
危害
一种名为跨站点脚本攻击可以窃取cookie信息, 通常跨站点脚本攻击往往利用网站漏洞在网站页面中植入脚本代码或网站页面引用第三方法脚本代码，均存在跨站点脚本攻击的可能，在受到跨站点脚本攻击时，脚本指令将会读取当前站点的所有 Cookie 内容（已不存在 Cookie 作用域限制），然后通过某种方式将 Cookie 内容提交到指定的服务器（如：AJAX）。
建议开发人员在向客户端 Cookie 输出敏感的内容时（譬如：该内容能识别用户身份）：
- 设置该 Cookie 不能被脚本读取，这样在一定程度上解决上述问题。
- 对 Cookie 内容进行加密，在加密前嵌入时间戳，保证每次加密后的密文都不一样（并且可以防止消息重放）。
- 客户端请求时，每次或定时更新 Cookie 内容（即：基于第2小条，重新加密）
- 每次向 Cookie 写入时间戳，数据库需要记录最后一次时间戳（防止 Cookie 篡改，或重放攻击）。
- 客户端提交 Cookie 时，先解密然后校验时间戳，时间戳若小于数据数据库中记录，即意味发生攻击。
cookie传递流程:
- 当在浏览器地址栏中键入了Amazon的URL，浏览器会向Amazon发送一个读取网页的请求，并将结果在显示器上显示。
- 这时该网页在你的电脑上寻找Amazon网站设置的Cookie文件，如果找到，浏览器会把Cookie文件中的数据连同前面输入的URL一同发送到Amazon服务器。
- 服务器收到Cookie数据，就会在他的数据库中检索你的ID，你的购物记录、个人喜好等信息，并记录下新的内容，增加到数据库和Cookie文件中去。
- 如果没有检测到Cookie或者你的Cookie信息与数据库中的信息不符合，则说明你是第一次浏览该网站，服务器的CGI程序将为你创建新的ID信息，并保存到数据库中。
响应消息
应答报文格式如下：
状态行 － 通用信息头 － 响应头 － 实体头 － 报文主体
响应消息的第一行为下面的格式：
HTTP-VersionSPStatus-CodeSPReason-PhraseCRLF
- HTTP-Version表示支持的HTTP版本，例如为HTTP/1.1。
- Status-Code是一个三个数字的结果代码。主要用于机器识别。
- 1xx:信息响应类，表示接收到请求并且继续处理
- 2xx:处理成功响应类，表示动作被成功接收、理解和接受
- 3xx:重定向响应类，为了完成指定的动作，必须接受进一步处理
- 4xx:客户端错误，客户请求包含语法错误或者是不能正确执行
- 5xx:服务端错误，服务器不能正确执行一个正确的请求
- Reason-Phrase给Status-Code提供一个简单的文本描述。帮助用户理解。
举例
Response Header sview source
// 缓存控制
Cache-Control:max-age=3, must-revalidate
// 连接状态控制
Connection:keep-alive
// 资源编码类型
Content-Encoding:gzip
// 资源长度
Content-Length:15919
// 资源类型
Content-Type:text/html; charset=UTF-8
// 日期
Date:Tue, 27 Sep 2016 14:05:58 GMT
// 服务器端信息
Server:nginx/1.4.6 (Ubuntu)
//
Vary:Accept-Encoding, Cookie
// 高速缓存
WP-Super-Cache:Served supercache file from PHP
// 服务器端支持
X-Powered-By:PHP/5.5.9-1ubuntu4.14运作方式
基于HTTP协议的请求/响应模式的信息交互过程可分为四个步骤:
- 客户端与服务器需要建立链接, 如TCP链接.
- 连接建立后, 客户端想服务器发送一个请求, 请求报文由三部分组成: 请求行 + 消息报头 + 请求内容.
- 服务器接到请求后, 解析该请求并返回响应信息, 响应报文也由三个部分组成: 状态行 + 消息报头 + 响应内容.
- 客户端接收服务器所返回的信息并进行解析、处理和显示.
如果在以上过程中的某一步出现错误，那么产生错误的信息将返回到客户端，由显示屏输出。对于用户来说，这些过程是由HTTP自己完成的，用户只要用鼠标点击，等待信息显示就可以了。
参考文章:
———————————–
RESTFUL
———————————–
restful概述
restful一种软件架构风格，是设计风格而不是标准，只是提供了一组设计原则和约束条件。
它主要用于客户端和服务器交互类的软件。基于这个风格设计的软件可以更简洁，更有层次，更易于实现缓存等机制。
虽然REST受Web技术的影响很深，但是理论上REST架构风格并非绑定在HTTP上。然而，HTTP是唯一与REST相关的实例。
一些关键名词:
资源
资源是REST中最关键的抽象概念，它们是能够被远程访问的应用程序对象。一个资源就是一个标识单位，任何可以被访问或被远程操纵的东西都可能是一个资源。资源可以是静态的，也就是该资源的状态永远不会改变。相反，某些资源的状态可能随着时间推移呈现很大的可变性。这两种类型的资源都是有效的。
任何重要的资源都应该能够通过一个唯一的标识被访问。RESTful HTTP使用URI来识别资源。URI提供了Web通用的识别机制，它包含了客户端直接与被引用的资源进行交互时需要的所有信息。
统一资源接口
为了简化整体系统架构，REST架构风格包含了统一接口的概念。统一接口包含一组受限的良定义的操作，由它们进行资源的访问和操作。不论什么资源，都使用相同的接口。
统一接口独立于资源的URI，并且也不需要类似IDL的文件去描述可用的操作。RESTful HTTP的接口非常流行且广为使用。它包含标准的HTTP方法如GET，PUT和POST（浏览器使用它发出请求并提取页面）。
不幸的是，很多开发者认为实现RESTful应用就是用一种直接使用HTTP的方式，这种理解是错误的。举个例子，HTTP方法的实现必须要遵循HTTP规范的，而通过GET方法创建或修改对象是不遵守HTTP规范的。
表示
对资源的操纵永远是通过其表示实现的。资源可能永远不会在网络中传输，相反，传输的是资源的表示。资源的表示包括数据和描述数据的元数据，例如，HTTP头“Content-Type” 就是这样一个元数据属性。
统一接口举例:
| 方法 | 典型用法 |
|---|---|
| GET |
|
| DELETE |
|
| PUT |
|
| POST |
|
restful 与 http 区别
REST 定义了一组体系架构原则，您可以根据这些，包括使用不同语言编写的客户端如何通过 HTTP 处理和传输资源状态。所以在事实上，REST 对 Web的影响非常大，由于其使用相当方便，已经普遍地取代了基于 SOAP 和 WSDL 的接口设计。
个人理解：
- 首先REST只是一种风格，不是一种标准
- REST是以资源为中心的
- REST充分利用或者说极端依赖HTTP协议
参考文章:
- RESTFUL 百度百科
- RESTFUL 博客
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
