RESTful_基础知识

目录

目录

前言

RESTful

REST原则

REST的Web原则

分层系统原则

RESTful的实现

SOA 面向服务的体系结构

RPC样式 Web服务

RPC的实现过程

SOAP 简单对象访问协议

RPC样式架构构建的基于SOAP的Web服务传输信封

RESTful Web服务

REST-RPC Web服务

RESTful Web服务的多层架构

Web服务的自动化客户端和表示层处理程序

Web应用程序的客户端和表示层处理程序

业务逻辑层

数据访问层

数据存储层

最后

前言

本篇主要是RESTful的基础知识整理，主要是为了将要开始的Openstack架构主题做知识积累。理解好RESTful的设计思想无论是对学习Openstack架构还是Openstack Dashboard实现都是一件事半功倍的事情。

RESTful

REST(Representational State Transfer)：是一种软件架构的设计风格，而不是一种标准。主要用于C/S架构的软件设计，也能很好的支持B/S架构，为软件设计提供了一组原则和约束条件，但这是原则和约束的条件均不具有标准性。

所以也可以将REST理解为是一组没有严格标准的架构约束条件和设计原则。能够使设计出来的软件简洁、可扩展、安全可靠、更有层次、更易于实现缓存机制。REST的软件设计倾向于简单轻量的方法设计和实现，以及REST具有通过HTTP直接传输数据的特性。

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

RESTful：即满足REST约束条件和原则的应用程式或设计，就是RESTful

REST原则

REST的Web原则

无状态原则：

在Web应用程序中，最重要的REST原则是：Client和Server间的交互请求是无状态的。在REST中，每一个对象都是通过URL来表示，对象用户负责将状态信息打包进每一条信息内，保证对象的处理总是无状态的。

交互原则：

而且从Client到Serser的每一个请求都必须包含理解请求所需要的信息，如果Server在Client的请求过程中重启了，Client不会得到Server的响应通知。但是，无状态的请求可以由任何可用Server来响应。使用REST架构设计的系统，可以扩展到大量的Client中，并且降低了Client与Server之间的交互延迟。这十分合适云计算的环境。客户端也可以缓存数据来改进其性能。

资源：

在Server端中的应用程序状态和功能都可以抽象为一种资源，如：应用程序对象、数据库记录、算法等，这些资源以URI(Universal Resource Identifier)的方式向Client公开。每一个资源映射到一个URI，URI作为资源的唯一标识。

HTTP标准方法：

因为所有的资源又都共享统一的接口，便于Client和Server之间使用标准的HTTP方法(GET、PUT、POST、DELETE)来传输信息。

分层系统原则

分层系统：

为了使得系统中的组件无法了解除了与它自身交互的中间件之外的任何组件。通过将不同的组件分别限制在各自的层面上，可以限制整个系统的复杂性，促进了底层的独立性。并且使用统一的Dashboard可以简化整个系统的后端架构，改进子系统之间交互的可见性。即：简化了Client和Server的实现。

中间件：

中间件是一种独立的系统软件或服务程序，能够连接两个独立软件或系统。分布式应用软件借助于中间件能够在不同的技术之间共享资源。即：中间件使得若干个相互独立的系统，在各自都拥有着不同的接口的情况下，仍然能通过中间件来实现通信。执行中间件的一个关键途径是信息的传递。通过中间件，应用程序可以工作在多个平台及OS环境中。简而言之，中间件即桥梁。

RESTful的实现

在理解RESTful的Web服务之前，首先来了解了解与之相似的另外一种实现方法—— RPC样式 Web服务

SOA 面向服务的体系结构

SOA(面向服务的体系结构)：是一个组件模型，它通过在应用程序中不同的服务(功能单元)之间定义良好的接口和契约，使得不同的服务之间可以联系起来。这些接口是采用中立的方式进行定义的，接口独立于实现服务的硬件平台、OS和编程语言。

SOA能够让这些构建在各种系统中的服务可以使用一种统一和通用的方式进行交互。

SOA可以根据需求通过网络对松耦合的粗粒度应用组件进行分布式部署、组合和使用。服务之间通过简单、精确定义的接口进行通信，不需要了解底层编程接口和通信模型。服务层是SOA的基础，可以直接被应用程序调用，从而有效的控制系统中与软件代理交互的人为依赖性。

SOA能够让软件工程师们站在一个新的高度去理解企业级架构中的各种组件的开发、部署形式，它将有利于企业系统架构师更迅速、可靠、更具重用性的架构整个业务系统。

RPC样式 Web服务

RPC的实现过程

RPC(Remote Procedure Call Protocol 远程过程调用协议)，是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议(TCP/UDP)的存在，为程序的通信携带信息数据。

RPC采用C/S架构，Client请求服务，Server提供服务。Client的调用进程发送一个有进程参数的信封(包含参数的调用信息)到Server的服务进程，然后等待回应。Server的服务进程会保持睡眠状态来等待Client发送的调用信息，当一个调用信息到达Server后，Server的服务程序就会获得参数、并将执行后的结果响应给Client，然后返回睡眠状态等待下一个调用信息。最后Client调用进程接收到响应信息后，得以继续执行程序。

SOAP 简单对象访问协议

SOAP(简单对象访问协议)：是交换数据的一种协议规范，是一种轻量级的、简单的、基于XML的协议，SOAP被设计成在Web上交换结构化和固化的信息。与WADL(Web Services Descruption Language)、UDDI(Universal Description Discovery and Integration)并称为Web Servicve三要素。SOAP可以和HTTP(超文本传输协议)、SMTP(简单邮件传输协议)等，现存的许多Internat协议和格式结合使用。而且还支持从消息系统到RPC(远程过程调用)等应用程序。SOAP使用了基于XML的数据结构和HTTP(超文本传输协议)的组合来定义一个标准的方法，并以这种方法来使用Internat上各种不同操作环境中的分布式对象。

WADL：描述如何访问具体的接口

UDDI：管理、分发、查询Web Services

RPC样式架构构建的基于SOAP的Web服务(传输”信封”)

这是实现SOA最常用的方法，RPC样式的Web服务Client将一个包含了数据(方法、参数信息)的信封通过HTTP协议发送到Server，Server将信封打开并接收传入的参数、执行指定的方法，然后将方法执行后的结果再次打包成一个信封返回到Client。最后Client接收到来自Server的响应。在PRC样式的架构中，每一个对象都有自己独特的方法，且仅会公开一个URI来标识。

注意：RPC架构忽略了HTTP大部分特性且仅支持POST方法。

RESTful Web服务

RESTful Web服务通常可以通过自动客户端或代表用户的应用程序直接访问，在REST样式的Web服务中，每个资源都有一个地址URI(统一资源表示符)。而资源的本身就是方法调用的目标，方法列表对所有的资源都是一样的，这些方法都是标准方法，包括HTTP GET、PUT、POST、DELETE、HEADER、OPTIONS。

自动客户端：

自动化使得应用程序能够对在另一个应用程序中实现的对象进行操作，或者会将对象公开以便可以对其进行操作。自动客户端是可以对属于另一个应用程序公开的对象进行操作的应用程序。而公开对象的应用程序也被称之为自动服务器。自动客户端通过访问自动服务器中对象的属性和方法对这些对象进行操作。有下面两种类型：

1. 运行时：动态的获取相关服务属性和操作信息的Client

2. 编译时：拥有指定服务器属性个操作的静态信息的Client

在RPC样式的Web服务中关注的是方法，而在RESTRful样式的Web服务中关注的是资源。

REST-RPC Web服务

REST-RPC混合样式Web服务不使用信封来包装方法、参数、数据，是通过直接的HTTP传输数据，这一点与REST样式的Web服务是类似的。但这种混合样式不使用标准的HTTP方法来操作资源，它在HTTP请求的URI中就已经存储了方法信息。

RESTful Web服务的多层架构

RESTful Web服务的多层架构与动态Web应用程序的多层架构在许多方面上是类似的。参照下面的多层架构图。Web服务与Web应用程序的不同在于客户端的本质(自动化/GUI)和表示层(Presentation layer)处理程序。Web服务让业务逻辑(Business logic layer)和数据可以由自动客户端(由自动化脚本支持的WebServicesClient)和GUI客户端(BrowserClient)共享。

从数据访问中分离业务逻辑可以实现数据库的独立性，并且能够为各种类型的数据存储提供插件能力。

Web服务的自动化客户端和表示层处理程序

在自动化客户端(Web服务的客户端)中，包括了Python、Java等语言编写的脚本，它们代表用户以自动化样式来运行。自动化客户端在Web层向Resource Request Handler(资源请求处理程序，使用Jersey或Restlet框架实现)发送HTTP请求。自动客户端的无状态请求在头部包含了方法信息，即POST、GET、PUT、DELETE等方法的信息，这又将映射到Resource Request Handler中资源的相应操作。每个无状态请求都包含了理解请求所需要的信息，包括Resource Request Handler用来处理请求的凭据。从Web服务的客户端接收到请求后，Resource Request Handler会从业务逻辑层请求服务。Resource Request Handler会确定所有概念性的实体，系统将这些实体作为资源公开出去的同时为每一个资源分配唯一的一个URI。但是，概念性的实体在表示层是不存在的，它存在于业务逻辑层。Resource Request Handler使用Jersey或Restlet框架来实现，所以它是轻量级的，会将大量的工作委托给业务逻辑层。

Web应用程序的客户端和表示层处理程序

Web浏览器客户端(GUI客户端)，使用表示层中的Browser Request Handler(浏览器请求处理程序)生成的HTML来提供显示功能。Browser Request Handler可以使用MVC、MTV模型。它从浏览器接受请求，从业务逻辑层请求服务，再生成表示视图并对浏览器做出响应，表示视图提供给用户在浏览器中显示。表示视图不仅包含了内容，而且还包含了显示的属性，如HTML、CSS。在浏览器中运行且作为RESTful Web服务消费者的角色的Ajax、Flash等等都属于Web服务的客户端。Ajax和RESTful Web服务本质上是互补的，而且RESTful Web服务为Ajax提供了非常简单的API来处理服务器上资源之间交互。

业务逻辑层

业务逻辑层充当着数据访问层(Data access layer)和表示层之间数据交换的中间层，数据经过业务逻辑层的处理后以域对象或值对象的形式提供给表示层。从业务逻辑层中解耦Browser Request Handler和Resource Request Handler有助于促进代码的重用，并能实现灵活和可扩展的架构。

数据访问层

数据访问层提供了与数据存储层(Data store layer)的交互，数据访问层可以使用DAO设计模式或对象-关系映射解决方案来实现。数据访问层的作用在于针对不用的数据存储技术，都能够从业务逻辑层中分离数据访问代码。数据访问层还可以作为连接其他系统的集成点，可以成为其他Web服务的客户端。

DAO(Data Access Object)：数据访问对象。是一个面对对象的数据访问接口(API)，即连接数据库的接口。夹在业务逻辑层和数据库资源中间。

数据存储层

数据存储层包括了数据库系统、LDAP服务器、文件系统和企业信息系统。使用该架构，你可以看到RESTful Web服务能够灵活的成为任何企业数据存储统一的API，从而向以用户为中心的Web应用程序公开垂直数据，并部署自动化批量报告脚本。

最后

可能对于刚开始接触RESTful的小伙伴们不能太理解上面的内容，不过大可以放心本篇是作为一个概括性的文章，以后还会反复的对其中的内容做出扩充。

Jmilk

RPC web前端

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。