【软件开发架构平台】CH9 前后端分离架构概述

第一次前后端分离（半分离）

Web 开发模式演变

• 早期时代（Servlet=JSP）

• • 不适合复杂的业务逻辑

  • 可维护性差

  • 协作性差

  • 难有交互

• MVC时代

• • 可维护性好转
  • 前后端分工，但是分工不明确
  • 前端重度依赖后端，体验不好

• AJAX时代（HTML:WEB服务器、CSS,JS：应用服务器）

• • 前后端分工清晰，开始强调用户体验
  • 前端不再强依赖后端
  • 请求由程序员用AJAX发出

• WEB服务器（CDN）：安装了Web服务器应用的物理主机的泛称

• • 功能：处理HTTP协议栈、文件映射系统、IO、 多线程处理请求/响应、日志记录、代理服务
    ex.Apache，Nginx

• 应用服务器：能编译、运行JavaWeb业务代码的服务器

• • ex.Tomcat（WEB服务器+WEB容器）、JBoss

• CDN：内容分发网络

• • 功能：降低网络拥塞
  • 技术：内容存储、分发技术
  • 会将前端静态页面采用CDN进行部署

• SPA时代（前后端分离）

• • 单页面；前端采用MVC
  • 可维护性提高
  • 前后端接口约定很重要，前端复杂度控制

• 第一次前后端分离（MVVM）

• • 接口分离，后端只提供数据（Model，Restful API），前端独立实现
  • 前端：浏览器跑大量JS代码，效率无法提高、接收数据，返回数据、处理渲染逻辑
  • 后端：提供数据、处理业务逻辑、代码跑在服务器上、Server-side MVC架构
  • 问题：分工（前端的Model和Controller的功能基本含绕后端重叠，只是实现技术不同）、性能（前端浏览器性能遇到挑战）、重用（数据校验需要做两次，前后端无法重用）、跨终端（需要重复实现）

第二次前后端分离（全分离）

后端	前端	前端
服务器	服务器	浏览器
JAVA	NodeJS	JS+HTML+CSS
服务层、提供数据接口、封装业务逻辑、维持数据稳定	跑在服务器上的JS；转发数据、串接服务；路由设计、控制逻辑；渲染页面，体验优化	跑在浏览器上的JS；JS/CSS加载和运行；DOM操作；共用模板、路由

NodeJS

• 服务端JS（JavaScript运行环境），让JS跑在服务器中，提高前端性能。（把操作DOM的功能去除，保留xhr语法支持和优化）
• 特性：事件驱动、非阻塞I/O

REST的基本概念

REST：表现层状态转移，一个符合REST设计的架构就可以称为RESTful架构

什么是REST?

• 资源：网络资源
• 表述性：将资源具体呈现出来的形式就称为资源的表述
• 状态转换：用户访问资源（和资源的互动）会导致资源的状态发生改变，用户使用网站或其他互联网应用的本质就是对服务器上的资源进行状态转换
• 如果这种状态是建立在资源表述的基础上（或是由资源表述来决定如何转换），就称为表述性状态转换（REST）
• REST是Web服务的一种设计思想
• 使用HTTP、URL、XML、JSON、HTML等广泛流行的标准和协议
• 轻量级、跨平台、跨语言的设计理念
• 是一种设计风格，不是一种标准，而是一种思想

REST六大约束

客户端-服务器：关注点分离、提高服务端简单性、客户端可移植性

无状态协议：会话信息保存在客户端，请求要包含所有信息而不依赖于上下文，提升服务端简单性、可靠性、可见性

缓存：响应内容应显式或隐式的被标为可缓存/不可缓存，减少客户端和服务端交互次数

分层系统：客户端不知道是和代理还是和真实服务器通信，尽可能将服务器端的安全、负载均衡、错误处理实现细节隐藏

按需代码：客户端可以直接从服务端下载部分代码，简化客户端

统一接口：所有接口统一使用restful设计思想

（1）资源标识：服务器任何资源都应通过URI进行唯一的标识

（2）通过表示操作资源：客户端持有资源的表述时，就应有足够的信息对资源进行操作

（3）响应的自描述性：每条响应消息都应该包含足够的信息来描述如何处理本条响应

（4）超媒体作为应用程序状态的引擎：点击连接跳转到另一个资源（REST API）

RESTful API设计指南

RESTful API请求设计规范（最佳实践）

• URI使用名词，且尽量是复数
• URI使用嵌套表示关联关系
• 使用正确的HTTP方法（GET \ POST \ PUT \ PATCH \ DELETE）
• 不符合CRUD的，使用POST+动词 、查询字段带action 字段或设计子资源三种方式中的某种方式

HTTP请求方式

• GET(SELECT)：从服务器获取资源（一项或多项）
• POST(CREATE)：在服务器新建一个资源
• PUT(UPDATE)：更新资源（客户端提供改变后的完整资源）
• PATCH(UPDATE)：部分更新资源（客户端提供需改变的部分资源）
• DELETE(DELETE)：删除资源
• HEAD：获取资源头部（元数据）
• POTIONS：获取资源信息，如某资源有哪些接口可以使用

RESTful API响应设计规范（过滤信息）

（1）GET方法的查询请求应提供信息过滤功能，包括分页等

• ？limit=10：返回记录的数量
  ?offset=10：返回记录的开始位置
  ?page=2&per_page=100：指定第几页，以及每页的记录数
  ?sortby=name&order=asc：指定返回结果按照哪个属性排序，以及排序顺序
  ?animal_type_id=1：指定筛选条件

（2）状态码

• 200：成功
  201：新建或修改数据成功
  202：请求已经进入后台
  204：删除数据成功
  400：发出的请求有错误，服务器没有新建或修改数据
  401：用户没有权限
  403：用户得到授权，但访问被禁止
  404：请求的是不存在的记录
  406：请求的格式不可得
  410：请求的资源被永久删除，不会再得到
  422：创建一个对象时，发生一个验证错误
  500：服务器发生错误，无法判断请求成功或失败
• 状态码非200的响应内容应包含错误信息，如：

{
	error: "Invalid API key"
}

（3）返回结果

• ·GET /collection：返回资源对象的列表
  ·GET /collection/resource：返回单个资源对象
  ·POST/collection：返回新生成的资源对象
  ·PUT/collection/resource：返回完整的资源对象
  ·PATCH/collection/resource：返回完整的资源对象
  ·DELETE/collection/resource：返回一个空文档

• （4）使用超链接

• {
  	"current_user_url": "https://api.github.com/user",
  	"authorizations_url":"...",
  }
  

• {
  	"message": "Requires authentication",
  	"documentation_url":"..."
  }
  

其它

• 网络协议使用HTTPs协议，而不是HTTP协议（HTTP不安全）
• 使用标准的身份认证和鉴权规范（如OAuth）
• 返回数据使用JSON而不是XML（解析XML对客户端要求较高）