RESTful API架构

什么是REST？

**REST（Representational State Transfer）**是种互联网软件架构模式，由 Roy Fielding 在他 2000 年的博士论文《架构风格与基于网络的软件架构设计》中提出，REST 一经提出就流行起来，迅速取代了复杂笨重的 SOAP。

REST 是一种系统架构设计风格，主要面向基于网络的软件架构设计。

这一架构风格，包含了以下一些基本要求：

客户-服务器 在 REST 风格中，最基本的要求就是应当分离用户接口和数据存储，改善用户接口跨平台迁移的可移植性，同时简化服务器组件，改善系统的可伸缩性。

客户端负责与用户之间的交互处理，而服务器端则实现数据存储以及相关的业务逻辑。
无状态

服务端在设计接口时，应当设计为无状态接口。也就是说，服务器端不保存任何与客户端相关的状态上下文信息，客户端在每次调用服务端接口时，需要提供足够的信息，以供服务端完成操作。

无状态减少了服务端保存客户端相关上下文数据，这对于服务端带来的好处有：
- 更加容易的实现动态扩展，而不至于影响客户端使用
- 减少了服务端从故障中恢复的任务量
缓存

应当在接口设计中增加缓存策略，服务端可以决定是否可以缓存当前返回的数据。通过此种方式，可以在一定程度上减少实际到达服务端请求，从而提高网络访问性能。

缓存的好处：减少实际到达服务端请求，从而提高网络访问性能。

缓存的坏处：设计不当，将有可能导致大量的过期数据，进而影响系统运行。所以要合理的设置缓存，和缓存过期时间。

一般缓存：数据字典类数据、修改频率非常低的数据、实时性要求很低的数据等
系统分层

在设计系统，尤其是大型系统，通常需要将系统按照不同的功能进行横向和纵向的分层。

横向分层：交互层、服务层、数据层等

纵向分层：按照不同的业务功能对系统进行切分

分层后，各模块可以独立进化，实现功能解耦，提高整个系统的可扩展性。
统一接口

统一接口，即是不同系统模块之间的调用接口统一规范，使用统一的调用协议，统一的数据格式等。统一接口带来的是系统交互的规范化，接口调用与业务解耦，各模块独立进化。

什么是RESTful？

如果一个架构符合REST原则，就称它为RESTful架构

REST 是 **Representational State Transfer （表现层状态转化）**的缩写。

RESTful架构三个概念：

面向资源（Resources）：每种资源都对应与一个 URI （统一资源标识符）地址。
表述性（Representation）：把"资源"具体呈现出来的形式，叫做它的"表现层"，URI是资源的位置，表现层提现在 HTTP 头信息中的Accept 和 Content-Type
状态转化（State Transfer）：客户端想要操作服务器，必须通过某种手段，让服务器端发生"状态转化"。而这种转化是建立在表现层之上的。体现在 HTTP头信息中的四种操作方式：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源

RESTful API 设计

什么是Restful API？

在 REST 提出多年来，当前对于 REST 风格的应用最多的即是 Restful API

Restful API 分为对外接口和对内接口

对外：面向公网的公共服务接口，对外接口尽可能使用安全认证。
对内：一整套系统内部各个子系统或模块之间交互的标准接口，相对于对外接口，对内接口更标准化。

HTTPS + 域名

在提供 Restful API ，特别是对外的 API 时，应当尽可能的使用 HTTPS 协议，以确保传输过程的安全。
在 API 地址中使用域名，可以进一步解耦服务端与客户端，服务端可以更加容易的迁移和扩展，而不会影响服务端的使用。

URL 指向资源，HTTP 动词指向操作

Restful API 的 URL 地址应指向具体的一个资源，例如用户 user 。URL 中应当只包含资源名词，不应该包含指向操作的动词，例如新建、查询、修改、删除等。具体操作通过 HTTP 动词（ GET / POST / PUT / DELETE ）指定。

https://open.domain.com/app/getUser # 传统接口
https://open.domain.com/app/addUser # 传统接口

https://open.domain.com/app/user # Restful Api 风格
# HTTP 指定动作
GET /user：列出所有用户
POST /user：新建一个用户
GET /user/ID：获取某个指定用户的信息
PUT /user/ID：更新某个指定用户的信息（提供该用户的全部信息）
PATCH /user/ID：更新某个指定用户的信息（提供该用户的部分信息）
DELETE /user/ID：删除某个用户

Restful API 设计注意点：

指定版本号：可以在URL、也可以在HTTP头信息中指定

https://open.domain.com/v1/app/user # 版本号放入 URL
https://open.domain.com/app/user # 头信息指定
HTTP header：
Accept: vnd.example-com.foo+json; version=1.0

参数提交：可以通过 URL参数和查询字符串方式

https://open.domain.com/v1/app/user/123 # URL参数
https://open.domain.com/v1/app/user?ID=123 # 查询字符串方式 QueryString

安全机制：特别是对公网开放的 Restful API，通常需要通过一定的安全认证机制来进行实现访问控制。目前主流的方案是通过 OAuth2.0 实现安全认证
返回数据：返回的数据应是 JSON 格式
资源自描述性：返回结果中提供链接，连向其他API方法，使得用户不查文档，也知道下一步应该做什么。这样用户只要记住一个 URL，就可以发现其他 URL。这种方法叫做 HATEOAS。比如 GitHub 的 API 都记载在 api.github.com

RESTful API vs RPC

优势：高效简洁

面向资源的接口设计，相对于传统 RPC 降低了接口设计的复杂度。
相对于 SOAP/XML 形式的 RPC 服务，Restful API 采用 HTTP/JSON 的形式传递数据，降低了传输数据量，同时提高了数据解析的效率，单位时间内的负载能力会高于 SOAP WebService 服务。

劣势：

对于一些复杂操作来说，接口设计难度将远大于 RPC 形式：如用户登录、商品下单。
没有类似于 SOAP 协议的规范性协议：

Restful API 中的数据格式、标准、安全性等都需要由开发者决定，这也就造成了无法建立统一的 Restful API 标准，作为客户端可能需要适配多种格式的 Restful API

什么是REST？​

什么是RESTful？​

RESTful API 设计​

什么是Restful API？​

HTTPS + 域名​

URL 指向资源，HTTP 动词指向操作​

RESTful API vs RPC​

优势：高效简洁​

劣势：​

参考​