SiteServer CMS 博客

为什么SiteServer CMS使用Restful编写API?

2018年02月10日



2018年2月1日,SiteServer CMS官方宣布发布全新版本V6.0预览版。此次发布的SiteServer CMS V6.0,官方对Siteserver CMS架构、二次开发方式、后台UI界面都做了较大的改进,尤其是在API方面,采用了Restful进行架构。这是为什么呢?

一、什么是Restful和Restful API?

Representational State Transfer,翻译是”资源在网络中以某种形式进行状态转移”。 REST本身并没有创造新的技术,面向资源是REST最明显的特征,对于同一个资源的一组不同的操作。REST要求必须通过统一的接口来对资源执行各种操作。对于每个资源只能执行一组有限的操作。

凡是符合REST架构设计的API都可以叫做Restful API,REST是世界上最成功的分布式应用架构风格,最为经典的莫过于Github API了。


二、Restful的特点

  • Client和Server端进一步解耦
    提高客户端的便捷性(操作简单),简化服务器提高可伸缩性(高性能、低成本),允许客户端服务端分组优化,彼此不受影响。

  • 无状态
    来自客户的每一个请求必须包含服务器处理该请求所需的所有信息(请求信息唯一性);提高可见性(可以单独考虑每个请求)、可靠性(更容易故障恢复)、可扩展性(降低了服务器资源使用)。

  • 可缓存
    客户端可以重用之前的请求信息发送请求,减少交互连接数和连接过程的网络时延。

  • 统一接口
    客户和服务器之间通信的方法必须是统一化的。提高交互的可见性,鼓励单独优化改善组件。

  • 分层系统
    通过限制组件的行为(即,每个组件只能“看到”与其交互的紧邻层),将架构分解为若干等级的层。

  • 按需代码
    支持通过下载并执行一些代码(例如Java Applet、Flash或JavaScript),对客户端的功能进行扩展。


三、如何理解Restful?

要深入理解REST,需要理解REST的五个关键词:

  • 资源(Resource)

  • 资源的表述(Representation)

  • 状态转移(State Transfer)

  • 统一接口(Uniform Interface)

  • 超文本驱动(Hypertext Driven)

3.1 什么是资源?

资源是一种看待服务器的方式,即,将服务器看作是由很多离散的资源组成。每个资源是服务器上一个可命名的抽象概念。因为资源是一个抽象的概念,所以它不仅仅能代表服务器文件系统中的一个文件、数据库中的一张表等等具体的东西,可以将资源设计的要多抽象有多抽象,只要想象力允许而且客户端应用开发者能够理解。与面向对象设计类似,资源是以名词为核心来组织的,首先关注的是名词。一个资源可以由一个或多个URI来标识。URI既是资源的名称,也是资源在Web上的地址。对某个资源感兴趣的客户端应用,可以通过资源的URI与其进行交互。

3.2 什么是资源的表述?

资源的表述是一段对于资源在某个特定时刻的状态的描述。可以在客户端-服务器端之间转移(交换)。资源的表述可以有多种格式,例如HTML/XML/JSON/纯文本/图片/视频/音频等等。资源的表述格式可以通过协商机制来确定。请求-响应方向的表述通常使用不同的格式。

3.3 什么是状态转移?

状态转移(state transfer)与状态机中的状态迁移(state transition)的含义是不同的。状态转移说的是:在客户端和服务器端之间转移(transfer)代表资源状态的表述。通过转移和操作资源的表述,来间接实现操作资源的目的。

3.4 什么是统一接口?

REST要求,必须通过统一的接口来对资源执行各种操作。对于每个资源只能执行一组有限的操作。以HTTP/1.1协议为例,HTTP/1.1协议定义了一个操作资源的统一接口,主要包括以下内容:
7个HTTP方法:GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS
HTTP头信息(可自定义)
HTTP响应状态代码(可自定义)
一套标准的内容协商机制
一套标准的缓存机制
一套标准的客户端身份认证机制

REST还要求,对于资源执行的操作,其操作语义必须由HTTP消息体之前的部分完全表达,不能将操作语义封装在HTTP消息体内部。这样做是为了提高交互的可见性,以便于通信链的中间组件实现缓存、安全审计等等功能。

3.5 什么是超文本驱动?

“超文本驱动”又名“将超媒体作为应用状态的引擎”(Hypermedia As The Engine Of Application State,来自Fielding博士论文中的一句话,缩写为HATEOAS)。将Web应用看作是一个由很多状态(应用状态)组成的有限状态机。资源之间通过超链接相互关联,超链接既代表资源之间的关系,也代表可执行的状态迁移。在超媒体之中不仅仅包含数据,还包含了状态迁移的语义。以超媒体作为引擎,驱动Web应用的状态迁移。通过超媒体暴露出服务器所提供的资源,服务器提供了哪些资源是在运行时通过解析超媒体发现的,而不是事先定义的。从面向服务的角度看,超媒体定义了服务器所提供服务的协议。客户端应该依赖的是超媒体的状态迁移语义,而不应该对于是否存在某个URI或URI的某种特殊构造方式作出假设。一切都有可能变化,只有超媒体的状态迁移语义能够长期保持稳定。

一旦理解了上述REST的五个关键词,就很容易理解REST风格的架构所具有的6个的主要特征。


四、使用Restful的优势

从面向实用的角度来看,REST架构风格可以为Web开发者带来三方面的利益:

4.1 简单性

采用REST架构风格,对于开发、测试、运维人员来说,都会更简单。可以充分利用大量HTTP服务器端和客户端开发库、Web功能测试/性能测试工具、HTTP缓存、HTTP代理服务器、防火墙。这些开发库和基础设施早已成为了日常用品,不需要什么火箭科技(例如神奇昂贵的应用服务器、中间件)就能解决大多数可伸缩性方面的问题。

4.2 可伸缩性

充分利用好通信链各个位置的HTTP缓存组件,可以带来更好的可伸缩性。其实很多时候,在Web前端做性能优化,产生的效果不亚于仅仅在服务器端做性能优化,但是HTTP协议层面的缓存常常被一些资深的架构师完全忽略掉。

4.3 松耦合

统一接口+超文本驱动,带来了最大限度的松耦合。允许服务器端和客户端程序在很大范围内,相对独立地进化。对于设计面向企业内网的API来说,松耦合并不是一个很重要的设计关注点。但是对于设计面向互联网的API来说,松耦合变成了一个必选项,不仅在设计时应该关注,而且应该放在最优先位置。


当然,永远不存在适用于任何运行环境的、包治百病的银弹式架构。REST是一种为运行在互联网环境中的Web应用量身定制的架构风格。今天,REST在互联网这个运行环境之中已经占据了统治地位,包括SiteServer CMS在内的各种主流的Web开发框架,都已大力支持REST开发的了。