详解HTTP协议与RESTFUL

被编码为 key/value 格式发送到服务器（表单默认的提交数据的格式）

ultipart/form-data ： 需要在表单中进行文件上传时，就需要使用该格式。

5.HTTP链接

当单击某个链接时，其中标签就会使用类似href属性值，指向一个网络地址Last Page。一个完整的网址遵循以下规则:

protocol、host、port、path、parameter、anchor。

scheme://host.domain:port/path/filename

Scheme 定义因特网服务的类型。最流行的类型是 http。

domain（域）定义因特网域名，比如：3wschool.com.cn。

host（主机）定义此域中的主机。如果被省略，缺省的支持 http 的主机是 www。

:port(端口)定义主机的端口号。端口号通常是被省略的。缺省的端口号是 80。

path（路径）定义服务器上的路径（一个辅助的路径）。如果路径被省略，则资源会被定位到网站的根目录。

filename是文档名称，缺省的文件名一般是default.jsp或index.html，根据web服务器设置的其它文件名。

大部分URL遵循一种标准格式，该格式包括三个部分；

（1）以怎样的方式访问资源

(2)服务器的位置，客户端资源在何处

(3) 指定服务器上某个特定资源

大多数 URL 的语法都建立在下面 9 个部分构成的通用格式上：

://

: @

: / ; ?

#

其中最重要的 3 个部分是：方案（scheme）、主机（host）和路径（path）

6.RESTful

REST 指的是一组架构约束条件和原则。” 如果一个架构符合 REST 的约束条件和原则，就称它为 RESTful 架构。隐藏在 RESTful 背后的理念就是使用 Web的现有特征和能力，更好地使用现有 Web 标准中的一些准则和约束。虽然 REST 本身受 Web技术的影响很深， 但是理论上 REST 架构风格并不是绑定在 HTTP 上，只不过目前 HTTP 是唯一与 REST 相关的实例。 所以我们这里描述的 REST 也是通过 HTTP 实现的 REST。

关于REST原则，从以下这几个方面去理解。

资源与 URI

统一资源接口

资源的表述

资源的链接

状态的转移

资源与 URI

资源可以是实体(例如手机号码)，也可以只是一个抽象概念(例如价值) 。下面是一些资源的例子：

某用户的手机号码

某用户的个人信息

最多用户订购的 GPRS 套餐

两个产品之间的依赖关系

某用户可以办理的优惠套餐

URI(Uniform Resource Identifier)就是标识资源，并且是唯一标识。URI 既可以看成是资源的地址，也可以看成是资源的名称。如果某些信息没有使用 URI 来表示，那它就不能算是一个资源， 只能算是资源的一些信息而已。以 github 网站为例，给出一些还算不错的 URI：

https://github.com/git

https://github.com/git/git

https://github.com/git/git/blob/master/block-sha1/sha1.h

https://github.com/git/git/commit/e3af72cdafab5993d18fae056f87e1dd08

https://github.com/git/git/pulls

https://github.com/git/git/pulls?state=closed

https://github.com/git/git/compare/master…next

统一资源接口

RESTful 架构应该遵循统一接口原则，统一接口包含了一组受限的预定义的操作，不论什么

样的资源，都是通过使用相同的接口进行资源的访问。如使用GET，PUT，POST，并遵循这些方法的语义。

RESTful 架构的主要原则

网络上的所有事物都被抽象为资源。

每个资源都有一个唯一的资源标识符。

同一个资源具有多种表现形式(xml,json 等)。

对资源的各种操作不会改变资源标识符。

所有的操作都是无状态。

符合 REST 原则的架构方式即可称为 RESTful。

REST 主要对以下两方面进行了规范

定位资源的URL风格，如

https://www.baidu.com/v/web/first/course

https://www.baidu.com/v/web/second/course

采用HTTP协议规定的GET、POST、PUT、DELETE动作处理资源的增删改查操作。

RESTful API 设计

API 与用户的通信协议，总是使用 HTTPs 协议。尽量将 API 部署在专用域名之下，https://api.example.com，如果API很简单，不会有进一步扩展，可以考虑放在主域名下。https://example.org/api/

版本

应该将 API 的版本号放入 URL。

https://api.example.com/v1/

另一种做法是，将版本号放在 HTTP 头信息中，但不如放入 URL 方便和直观。Github 采用这

种做法。

路径（Endpoint）

表示 API 的具体网址。在 RESTful 架构中，所用的名词往往与数据库的表格名对应。一般来说，数据库中的表都是同种记录的”集合”（collection）。

如通过API提供动物园信息，包括动物和雇员信息，则路径应该设计成如下:

https://api.example.com/v1/zoos

https://api.example.com/v1/animals

https://api.example.com/v1/employe

常用的 HTTP 动词有下面五个（括号里是对应的 SQL 命令）。

GET（SELECT）： 从服务器取出资源（一项或多项）。

POST（CREATE）： 在服务器新建一个资源。

PUT（UPDATE）： 在服务器更新资源（客户端提供改变后的完整资源）。

PATCH（UPDATE）： 在服务器更新资源（客户端提供改变的属性）。

DELETE（DELETE）： 从服务器删除资源。

还有两个不常用的 HTTP 动词。

HEAD： 获取资源的元数据。

OPTIONS： 获取信息，关于资源的哪些属性是客户端可以改变的。

举例说明:

GET /zoos： 列出所有动物园

POST /zoos： 新建一个动物园

GET /zoos/ID： 获取某个指定动物园的信息

PUT /zoos/ID： 更新某个指定动物园的信息（提供该动物园的全部信息）

PATCH /zoos/ID： 更新某个指定动物园的信息（提供该动物园的部分信息）

DELETE /zoos/ID： 删除某个动物园

GET /zoos/ID/animals： 列出某个指定动物园的所有动物

DELETE /zoos/ID/animals/ID： 删除某个指定动物园的指定动物

过滤信息（Filtering）

如果记录数量很多，服务器不可能都将它们返回给用户。API 应该提供参数，过滤返回结果。下面是一些常见的参数

?limit=10：指定返回记录的数量。

?offset=10：指定返回记录的开始位置。

?page=2&per_page=100：指定第几页，以及每页的记录数。

?sortby=name&order=asc：指定返回结果按照哪个属性排序，以及排序顺序。

?animal_type_id=1：指定筛选条件

允许 API 路径和 URL 参数偶尔有重复。比如，GET /zoo/ID/animals与 GET /animals?zoo_id=ID 的含义是相同的。

错误处理（Error handling）

如果状态码是 4xx，就应该向用户返回出错信息。一般来说，返回的信息中将 error 作为键名，出错信息作为键值即可。

{

error: “Invalid API key”

}

返回结果

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

GET /collection： 返回资源对象的列表（数组）

GET /collection/resource： 返回单个资源对象

POST /collection： 返回新生成的资源对象

PUT /collection/resource： 返回完整的资源对象

PATCH /collection/resource： 返回完整的资源对象

DELETE /collection/resource： 返回一个空文档

Hypermedia API

返回结果中提供链接，连向其他 API 方法，使得用户不查文档，也知道下一步应该做什么。当用户向 api.example.com 的根目录发出请求，会得到这样一个文档。

{ “link”: {

“rel”: “collection https://www.example.com/zoos”,

“href”: “https://api.example.com/zoos”,

“title”: “List of zoos”,

“type”: “application/vnd.yourformat+json”

}

}

link 属性，用户读取这个属性就知道下一步该调用什么 API 了。href 表示 API 的路径，title 表示 API 的标题，type 表示返回类型。

Hypermedia API 的设计被称为 HATEOAS。Github 的 API 就是这种设计，访问 api.github.com会得到一个所有可用 API 的网址列表。

{ “current_user_url”: “https://api.github.com/user”, “authorizations_url”: “https://api.github.com/authorizations”, // … }

如果想获取当前用户的信息，应该去访问 api.github.com/user，然后就得到了下面结果。

{

“message”: “Requires authentication”,

“documentation_url”: “https://developer.github.com/v3”

}

上面代码表示，服务器给出了提示信息，以及文档的网址。

(1) API 的身份认证应该使用 OAuth 2.0 框架。

(2) 服务器返回的数据格式，应该尽量使用 JSON，避免使用 XML。