15、REST接口初探之 REST

书接上文。

REST诞生于Roy Thomas Fielding的一篇博士论文中。在这篇论文中，首次提出了REST（Representational State Transfer）表述性状态转移。就像它的名字，不管是英文还是中文，都是那么拗口不好理解一样，其实它的理念同样不是那么容易理解。或许还有其它一些商业上的原因，导致这个术语及相关的概念很长一段时间里，并未被广泛地应用到实际中。

REST并不是一种全新的通信协议，也不是一种通信规范。作为HTTP协议（V1.0及V1.1两个版本）的主要设计者及Apache服务器作者之一，Roy 对Web应用有着深刻的理解。基于他的理解，他提出了一种软件架构的设计风格，命名为REST。REST提出了架构设计的一些约束条件和原则。主要包括无状态、缓存、统一接口、分层系统、客户端服务器等约束条件和原则。如果一个Web应用的架构符合这些条件，那么就可以称它是RESTful 的。通常Web应用都是通过一些API接口来暴露相应服务的，此时就称这些API是 RESTful 的。

本文不打算跟大家去讨论这些晦涩的约束条件和原则。如果你打算为自己的Web应用，增加对外提供访问的 RESTful API接口，那么建议你去仔细研究下这些约束条件和原则。以便你设计的 API 接口能被客户端顺畅地访问。

对于一种交互行为，SOAP的做法是先有动作，然后有参数。例如，对MP277的SOAP访问，是先定义了GetValue这个动作。为了执行这个动作，还需要为其提供一个参数，即动作是作用在哪个实体上的。类似的，OPC XML-DA 的数据交换中，也是先有 Read这个动作，然后再给出参数，要读哪个或哪些变量。并且大家可以看出，同样都是一个读的操作，就有GetValue和Read两个不同的名称。这种多样性其实给使用者带来了一定的麻烦。另外，SOAP是基于XML语言的。很明显，XML语言并不是一种简洁的表示语言。在描述性文本格式中，JSON格式因其结构轻巧，且与面向对象的Object更易结合，而越来越受欢迎。

同样对于一种交互行为，REST的做法是先有名词，而后有动词。这里面的名词，通常就是我们要访问的对象。这更符合面向对象的思考方式。而这些对象，通常就是我们要访问的网络资源。对于动词，即交互的动作，其实大部分应用就是创建新值、读取现值、更新旧值及删除旧值。

通过前面的HTTP讨论，大家应该看出来了，这四个动作其实就是HTTP的四种请求方法。对于要访问的对象，网络资源，可以通过URL来表示。而URL是HTTP请求的一部分，完全可以由HTTP来实现。对于向资源发起的动作，可以通过HTTP的请求方法来区分。这样，借助HTTP协议本身的特性，REST就可以完成数据交互的操作。由于HTTP的标准使用非常广泛，因此REST就变得更易于使用，而且更通用。

下面以WinCC V7.5 SP2的REST接口来说明。

为了读取WinCC变量tag01的值，访问REST接口的 HTTP 报文如下所示：

先分析下“请求行”中的内容。

 GET：这是REST中对资源的操作方式。GET表示获取，这里代表“读”操作。

/WinCCRestService/tagManagement/Value/tag01：这个URL路径是相对的。

“WinCCRestService”表示访问的是WinCC 的REST服务。

“tagManagement”表示是针对变量管理相关的访问。

“Value”表示对变量值相关的操作。因为请求方法是GET，可知应该是读变量的操作。同时由于Value使用的是单数形式，表明是读一个变量值的操作。读哪个变量呢？

“tag01”就是要读的变量名称。

这样，通过请求方法及请求URL就明确了本次操作是要读取tag01数值。

Authorization: Basic d2luY2M6c2llbWVucw==：因为通过REST接口访问WinCC的变量，WinCC需要客户端提供身份认证。这里的参数用于提供用户名及密码。

Host: cc75:34568：这里给出了要访问的主机名称及端口号。

我们可以将上述的报文与SOAP的读数据的报文比较一下，不难发现该报文的结构更小巧，语义上也更易于理解。如果要访问多个变量，那么“请求”报文会变为如下的样子。

请求URL中的 Value会写成 Values。这很好理解，复数表示要读的变量不只一个。既然要读多个变量，那自然需要告诉REST接口各个变量的名称。显然此时将各个变量名称列在请求URL中并不是一种好办法。所以，将多个变量名称放到 HTTP 的Body中就是顺理成章的事情。所以在Body中增加了一个由 { } 括起来的对象，该对象的名称是variableNames，值是一个列表。列表中包含了两个变量名称 tag01 和tag02。

不管是读单个变量，还是读多个变量，REST接口的响应看起来也更简洁些。如下是读取多个变量时的响应内容。

“响应行”及“响应头”完全符合HTTP的规范。“响应体”中的JSON格式内容，简洁且表达清晰。使用JSON解析功能很容易得到不同变量的类型、当前数值、时间戳、质量代码及错误代码等信息。

通过这些讨论，我们可以看出。所谓的REST架构，其实就是充分利用HTTP的请求URL来构成语义及逻辑更清晰的资源对象。针对这个资源对象，充分利用HTTP自有的请求方法，来完成对资源对象的常用操作。同时利用JSON数据格式的简洁与易操作性。从而实现以一种更便捷的形式，来对Web服务中各种资源的读写访问。

至此，以HTTP为基础，我们已经讨论了两种Web访问技术SOAP及REST的理念及实现的差异。我们无意评价其好坏，存在即合理，各有各的应用场合。本文的讨论只是基于技术的角度，试图去揭示这些技术之间的关联。目的是希望广大会员朋友能真正理解当下流行的 REST，到底是什么，怎么工作的。另外，通过对相关概念的理解，也方便大家在应用REST的时候，有的放矢地进行调试。

由于文章篇幅及个人能力的限制，作为一个OT工程师，我不敢保证文中所述之IT技术关键点绝对全面、绝对专业。谬误之处，欢迎不吝指正。若本文对你理解REST概念起到了抛砖引玉的效果，则足矣。

【声明：本文/视频版权归西门子1847工业学习平台所有，未经允许，不得转载。】