笔记-restful

笔记-restful

1.      restful简介

restful:representational state transfer，简称REST，描述了一个架构样式的网络系统。

值得注意的是REST并没有一个明确的标准，而更像是一种设计的风格。

REST的全概念包括系统设计，架构等，但一般情况下提到的REST多代指网络程序接口设计风格。

REST是一个标准，一种规范，遵循REST风格可以使开发的接口通用，便于调用者理解接口的作用。

1.1.    REST风格

按REST规范实现的网络应用系统需要遵守以下规则：

1. 客户-服务器（Client-Server），提供服务的服务器和使用服务的客户需要被隔离对待。
2. 无状态（Stateless），来自客户的每一个请求必须包含服务器处理该请求所需的所有信息。换句话说，服务器端不能存储来自某个客户的某个请求中的信息，并在该客户的其他请求中使用。
3. 可缓存（Cachable），服务器必须让客户知道请求是否可以被缓存。（Ross：更详细解释请参考 理解本真的REST架构风格 以及 StackOverflow 的这个问题 中对缓存的解释。）
4. 分层系统（Layered System），服务器和客户之间的通信必须被这样标准化：允许服务器和客户之间的中间层（Ross：代理，网关等）可以代替服务器对客户的请求进行回应，而且这些对客户来说不需要特别支持。
5. 统一接口（Uniform Interface），客户和服务器之间通信的方法必须是统一化的。（Ross：GET,POST,PUT.DELETE, etc）
6. 支持按需代码（Code-On-Demand，可选），服务器可以提供一些代码或者脚本（Ross：Javascrpt，flash，etc）并在客户的运行环境中执行。这条准则是这些准则中唯一不必必须满足的一条。（Ross：比如客户可以在客户端下载脚本生成密码访问服务器。）

1.2.    REST实现

HTTP1.1是比较符合REST规范的一个案例，下面结合HTTP具体讲解一下REST规范。

关键词：

1. 资源（Resource）：简单点说就是可以增删改查的对象；
2. 资源的表述（Representation）：资源向外展露的形式，是封装/描述过的资源，毕竟直接暴露资源缺点太多；
3. 状态转移（State Transfer）：对资源的操作；
4. 统一接口（Uniform Interface）：

1.2.1.   资源与资源的表述

REST全称是表述性状态转移，那究竟指的是什么的表述? 其实指的就是资源。任何事物，只要有被引用到的必要，它就是一个资源。资源可以是实体(例如手机号码)，也可以只是一个抽象概念(例如价值) 。

要让一个资源可以被识别，需要有个唯一标识，在Web中这个唯一标识就是URI(Uniform Resource Identifier)。

URI既可以看成是资源的地址，也可以看成是资源的名称。如果某些信息没有使用URI来表示，那它就不能算是一个资源， 只能算是资源的一些信息而已。URI的设计应该遵循可寻址性原则，具有自描述性，需要在形式上给人以直觉上的关联。

以HTTP为例，客户端通过HTTP方法可以获取资源，对吧?

确切的说，客户端获取的只是资源的表述而已。 资源在外界的具体呈现，可以有多种表述(或成为表现、表示)形式，在客户端和服务端之间传送的也是资源的表述，而不是资源本身。 例如文本资源可以采用html、xml、json等格式，图片可以使用PNG或JPG展现出来。

资源的表述包括数据和描述数据的元数据，例如，HTTP头"Content-Type" 就是这样一个元数据属性。

那么客户端如何知道服务端提供哪种表述形式呢?

答案是可以通过HTTP内容协商，客户端可以通过Accept头请求一种特定格式的表述，服务端则通过Content-Type告诉客户端资源的表述形式。

1.2.2.   状态转移

状态转移基本就是增删改查了。

这里有三个概念:

1. 无状态通信：REST原则中提到了无状态通信原则。

乍一看，好像自相矛盾了，既然无状态，何来状态转移一说?

其实，这里说的无状态通信原则，并不是说客户端应用不能有状态，而是指服务端不应该保存客户端状态。

1. 应用状态与资源状态:

实际上，状态应该区分应用状态和资源状态，客户端负责维护应用状态，而服务端维护资源状态。

客户端与服务端的交互必须是无状态的，并在每一次请求中包含处理该请求所需的一切信息。

服务端不需要在请求间保留应用状态，只有在接受到实际请求的时候，服务端才会关注应用状态。

这种无状态通信原则，使得服务端和中介能够理解独立的请求和响应。

在多次请求中，同一客户端也不再需要依赖于同一服务器，方便实现高可扩展和高可用性的服务端。

但有时候我们会做出违反无状态通信原则的设计，例如利用Cookie跟踪某个服务端会话状态，常见的像J2EE里边的JSESSIONID。

这意味着，浏览器随各次请求发出去的Cookie是被用于构建会话状态的。

当然，如果Cookie保存的是一些服务器不依赖于会话状态即可验证的信息（比如认证令牌），这样的Cookie也是符合REST原则的。

1. 应用状态的转移:

状态转移到这里已经很好理解了， "会话"状态不是作为资源状态保存在服务端的，而是被客户端作为应用状态进行跟踪的。客户端应用状态在服务端提供的超媒体的指引下发生变迁。服务端通过超媒体告诉客户端当前状态有哪些后续状态可以进入。

这些类似"下一页"之类的链接起的就是这种推进状态的作用——指引你如何从当前状态进入下一个可能的状态。

1.3.    统一接口

RESTful架构应该遵循统一接口原则，统一接口包含了一组受限的预定义的操作，不论什么样的资源，都是通过使用相同的接口进行资源的访问。

在HTTP中它们就是GET，PUT和POST等命令，并遵循这些方法的语义。

1.4.    总结

rest是一种软件架构风格，一般而言如果软件的接口是 rest接口，那么就可以认为软件的接口是restful的。

关于REST与HTTP，因为HTTP是REST的一个非常好的实现标本，大家在开发时常依托于HTTP协议。经常使用的参考内容包括URL风格，命令名及操作，状态码等。

2.      附录

2.1.    REST 和 HTTP/1.1

讨论REST时总是离不开HTTP，具体它们之间有什么关系？

Roy Fielding （Apache HTTP 服务器的核心开发者，Apache 软件基金会的合作创始人，HTTP/1.1 协议专家组的负责人）总结了一套理论框架，然后使用这套理论框架中的指导原则，来指导HTTP/1.1协议的设计方向。后来他在其的博士学位论文 Architectural Styles and the Design of Network-based Software Architectures 中更为系统、严谨地阐述了这套理论框架，并且使用这套理论框架推导出了一种新的架构风格，并且为这种架构风格取了一个令人轻松愉快的名字 REST。

HTTP/1.1 的很多特性就是 REST 的特性，比如连接的无状态性。还有后面说的 REST 五大特性都和 HTTP/1.1 协议密不可分。

2.2.    参考文档：

1. http://www.ruanyifeng.com/blog/2018/10/restful-api-best-practices.html
2. http://www.runoob.com/w3cnote/restful-architecture.html
3. https://blog.csdn.net/qq_21383435/article/details/80032375