架构之RESTful

REST全称是Representtational State Transfer，意思是表现层状态转化

REST是一种软件架构风格，它本身并没有创建新的技术、组件或者服务。使用web的现有特征和能力，增加一些约束和准则。这里描述的REST也是通过HTTP实现的REST

 

1.资源

在REST中最重要的一个概念就是资源。在面向对象的世界里，我们提倡万物皆对象，而在REST的世界里则是万物皆资源。所谓“资源”，就是网络上的一个实体，或者说是网络上的一个具体信息。

2 表现层

“资源”是一种信息实体，可以有多种外在表现形式。我们把“资源”具体呈现出来的形式，叫做它的“表现层”

3 状态转化

访问一个网站，代表了客户端和服务器的一个互动过程。在这个过程中，势必涉及到数据和状态的变化。

当下的互联网通信协议 HTTP协议，是一个无状态协议。所以的状态保存在服务器端。因此，如果客户端想要操作服务器，必须通过某种手段，让服务器发生“状态转化”。而这种转化是建立在表现层之上的，所以就是“表现层状态转化”

在HTTP协议里面，就可以使用HTTP动词来对服务器端资源进行操作，实现“表现层状态转化”。如：GET、POST、PUT、DELETE。分别对应四种基本操作：GET用来获取资源，POST用来新建资源（也可用于更新资源），PUT用来更新资源，DELETE用来删除资源。

REST（表现层状态转化）---REST是一种通过表现层来操作改变资源的 状态的 软件架构风格。

 

RESTful API

RESTful API 就是REST风格的API。使用URI来描述资源，用Html、Json、XML等格式展现，通过HTTP动词来操作资源来实现状态转化，使用HTTP状态码反应处理结果。

 

URI

URI通常由三部分组成：

1.访问资源的命名机制

2.存放资源的主机名

3.资源自身的名称

例如：https://localhost/post/1(对应URLhttps://localhost/post/1.html)

可以这样解释

1.这是一个可以通过https协议访问的资源

2.位于主机localhost上

3.通过"post/1"可以对该资源进行唯一标识

注：以上三点是对实例的解释，并不是URI的必要条件，URI只是一种概念，怎样实现无所谓，只要它唯一标识一个资源就可以了。URI只代表资源的实体，不代表它的形式。严格的说，如上面网址最后的".html"后缀名是不必要的，因为最后这个后缀名标识格式，属于“表现层”范畴，而URI应该只代表“资源”的位置。

 

HTTP动词

常用的HTTP动词有下面这些

GET：从服务器取出资源（一项或多项）。——幂等
POST：在服务器新建一个资源。——非幂等
PUT：在服务器更新资源（客户端提供改变后的完整资源）。——幂等
PATCH：在服务器更新资源（客户端提供改变的属性）。——幂等
DELETE：从服务器删除资源。——幂等
HEAD：获取资源的元数据。
OPTIONS：获取信息，关于资源的哪些属性是客户端可以改变的。

 

状态码

HTTP协议本身给我们提供了丰富的状态码，以用来反映服务器端处理的结果。而在真正使用绝大多数人仅仅了解会使用200,504,500之流。而RESTful API规范的HTTP状态码的shiyong，使HTTP协议的优点发挥到了极致。

 

面向资源≠面向表单操作

他们没有任何关系，资源可以是一个文件，可以是缓存里的数据，也可以是数据库里多张表聚合的结果。比如用户这个资源，通常我们设计数据库的时候出于性能或范式的考虑用户的信息不会是放在一张表里。但是在API设计的时候用户就是一个资源，这个资源的数据可能是多张表，也可能是缓存。

 

优缺点和适用场景

任何一门技术或者思想都有其优缺点，虽然其诞生的初衷都是为了解决我们的问题，而不是带来更大的灾难。REST同样如此。它的优点很明显，优雅、规范，行为和资源分离，更容易理解。
但是也有其缺点，它面向资源，这种设计思路是反程序员直觉的，因为在本地业务代码中仍然是一个个的函数，是动作，但表现在接口形式上则完全是资源的形式，对于后端开发人员要求高，有些业务逻辑难以被抽象为资源的增删改查。甚至有些时候RESTful其实是个效率很低的东西，为了实现一个资源，你需要定义它的一套方式，如果要联合查询又会要求对其衍生或定义一个新的资源。它提供的接口一般是“粗”粒度的，它通常返回的都是完整的数据模型，难以查询符合特殊要求的数据，有些特殊的业务要比普通的API需要更多次HTTP请求。
REST面对的疑问跟当年刚开始流行面向对象时的情况是一样的。它适合很多情况，但并不适合所有情况。它更适合与一些开放平台API，如新浪微博、GitHub、京东、淘宝开放平台等，开放API之所以开放，就是因为它不知道你到底需要什么返回结果，既然不知道，那么我干脆都返回给你，有客户端自由组合成自己想要的数据。而对于内部开发，有其局限性，内部开发由于需求非常明确，有些时候出于性能或灵活性的考虑，服务端简单粗暴的丢出来完整的数据模型由客户端自己处理显然是不合适的。
对于一些内部的开发，适合用RESTful API的我们仍然可以用，对于一些不合适的，我们仍然可以借鉴一些RESTFul中的优点，来设计我们的API。比如简洁的URI(每个人看到一坨超长的API地址，内心都是拒绝的)，充分利用HTTP状态码等。

 

小结

RESTful API是REST风格的API，它是一种API设计风格，规范了API设计中的一些原则。它让我们的API更加优雅、规范。但也尤其缺点，在实际使用过程中我们应该充分的取理解它，综合考量其使用场景。