《SOA原理与技术》学习笔记（四）——Web服务实现和REST基础

《SOA原理与技术》学习笔记（一）——前言

《SOA原理与技术》学习笔记（二）——SOA技术概述

《SOA原理与技术》学习笔记（三）——Web服务基础

《SOA原理与技术》学习笔记（四）——Web服务实现和REST基础

《SOA原理与技术》学习笔记（五）——REST API设计和服务组合技术

《SOA原理与技术》学习笔记（六）——服务业务流程和企业服务总线ESB

四、Web服务实现

1. 【实验】

  在 Intellij IDEA 中创建并调用 WebService_开发工具
  在 Intellij IDEA 中远程调用已有的 WebServices
  在 Eclipse 下使用 Axis2 进行 WebServices 创建和发布

2. 如何开发自己的Web服务(Java平台为例)

1. 创建java项目，编写程序代码

2. 选中项目文件，利用 Axis2 Service Archiver 生成 .aar 文件

3. 将上一步生成的 .aar 文件拷贝到 axis2 下的 services目录下

4. 启动Tomcat，访问 axis2， 可以在服务列表中看到该服务的 WSDL 文档

5. 利用 Axis2 Code Generator 将 WSDL 文档生成 java 代码

6. 导入 Axis2 依赖包

7. 创建调用程序

   // 1.初始化桩模块
   WebServiceDemoStub helloWorldServiceStub = new WebServiceDemoStub();
   // 2.初始化SayHello的方法
   SayHello sayHello = new SayHello();
   // 3.传入参数
   sayHello.setName("summer");
   // 4.调用sayHello方法传给服务的响应
   SayHelloResponse sayHelloResponse = helloWorldServiceStub.sayHello(sayHello);
   System.out.print(sayHelloResponse.get_return());
   

3. 如何访问调用已有的Web服务(生成代理类)

五、REST基础

1. REST是什么、如何理解、有何关键特性

是什么：

REST是一种设计风格。它不是一种标准或协议，也不是一种技术，而是一种思想。

如何理解：

REST通常使用HTTP，URI，和XML以及HTML这些现有的广泛流行的协议和标准，来实现其要求的架构风格。

从资源的角度来观察整个网络

网络上的所有事物都是资源，分布在各处的资源由URI确定，而客户端的应用通过URI来获取资源的表述。

REST架构风格以资源为核心进行设计

对REST的字面理解：

• 资源（Resources）

  任何寄宿于Web可供操作的“事物”均可视为资源

• 表现层（Representation）

  "资源"具体呈现出来的形式

• 状态转化（State Transfer）

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

  让服务器端发生"状态转化"（State Transfer）。而这种转化是建立在表现层之上的，所以就是"表现层状态转化"。

三者之间的关联：

• 采用URI标识资源

• 使用统一的接口

• 使用标准的HTTP方法

  为什么可以这么做？

  由于RESTful Web API采用了同一的接口，所以其成员体现为针对同一资源的操作。对于Web来说，针对资源的操作通过HTTP方法来体现。我们应该将两者统一起来，是Web API分别针对CRUD的操作只能接受具有对应HTTP方法的请求。

• 支持多种资源表示方式

• 无状态性

  含义：

  不需要维护客户端的状态，每次请求都是全新的

  优势:

  不仅仅使Web API自身显得简单而精炼，还因减除了针对客户端的“亲和度（Affinty）”使我们可以有效地实施负载均衡，因为只有这样集群中的每一台服务器对于每个客户端才是等效的。

PUT 和 POST 的区别：

• 均可以添加一个新的资源

• POST：请求着一般不能确定标识添加资源最终采用的URI，即服务端最终为成功添加的资源指定URI

• PUT：最终标识添加资源的URI是可以由请求者控制的

• 如果发送PUT请求，我们一般直接将标识添加资源的URI作为请求的URI；

  对于POST请求来说，其URI一般是标识添加资源存放容器的URI。

六大特性：

• 客户端-服务器的

• 无状态的

• 可缓存的

• 统一接口

• 分层系统

• 按需编码

• 客户-服务器（Client-Server）
  通信只能由客户端单方面发起，表现为请求-响应的形式。

• 无状态（Stateless）
  通信的会话状态（Session State）应该全部由客户端负责维护。

• 缓存（Cache）
  响应内容可以在通信链的某处被缓存，以改善网络效率。

• 统一接口（Uniform Interface）
  通信链的组件之间通过统一的接口相互通信，以提高交互的可见性。

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

• 按需代码（Code-On-Demand，可选）
  支持通过下载并执行一些代码（例如Java Applet、Flash或JavaScript），对客户端的功能进行扩展。

2. Why REST

• 前后端分离
• 仅提供数据接口
• 多客户端
• 多语言支持

为什么要基于API开发：

• API让web，手机客户端，桌面多种操作成为可能，程序员分工更加明确，切降低了开发成本；
• 软件开发依赖解耦
• 软件开发依赖解耦

REST优势：

• 将用户界面和数据存储分离，提高用户界面跨多个服务平台
• 一个好的架构应该可以很轻松的为不同的请求返回不同格式的数据。
• 使用REST的最佳的场景是对外提供公开的服务，也就是所谓的OpenAPI，也有的人认为REST更适合资源导向的网站，像youtube这样的网站。
• REST 的真正价值在于 Web Services，而不是通过浏览器操作的应用程序。

3. REST与MVC的关联对比、与RPC的对比

REST与MVC风格的关联与对比：

• MVC风格将模型、视图、控制解耦，其结构整洁、逻辑清晰，易于扩展和增强。MVC偏重于解决服务器端的逻辑分层问题，以及客户端是逻辑分层的延伸问题。但是MVC很难实现跨语言解耦。

• REST风格偏重于统一接口，具体实现可以跨平台和跨语言。REST使用纯HTML作为客户端，没有服务器端和客户端的耦合。

• MVC和REST并不是互斥的，如Spring的MVC模块已经开始支持REST式的开发，Jersery也实现了MVC的功能。

REST式的API服务 V.S. RPC风格：

• REST服务是一种ROA（Resource Oriented Architecture）应用，其主要特点是方法信息存在于HTTP协议的方法中，作用域存在于URI中，风格更轻量和快速。
• 从方法信息角度，REST采用标准的HTTP方法，RPC请求都是HTTP协议的POST方法，其方法信息包含于SOAP协议包或HTTP协议包中，方法名称不具有通用性。
• 从作用域角度看，REST采用URI显示定义作用域，而RPC这一信息同样包含于协议包中，不能直观呈现。
• RPC风格的开发关注于服务器-客户端之间的方法调用，是面向方法调用过程的，而REST是面向资源状态的。
  备注：PRC风格的两个代表是XML-RPC和SOAP Service

TP协议的POST方法，其方法信息包含于SOAP协议包或HTTP协议包中，方法名称不具有通用性。

• 从作用域角度看，REST采用URI显示定义作用域，而RPC这一信息同样包含于协议包中，不能直观呈现。
• RPC风格的开发关注于服务器-客户端之间的方法调用，是面向方法调用过程的，而REST是面向资源状态的。
  备注：PRC风格的两个代表是XML-RPC和SOAP Service