一些REST架构设计模式的理解

最近在做的方向是o2o架构的一个网站设计，在这其中我们cto经常提出一个理念REST（你的接口不够REST啊！）所以我在网上查了一些关于

REST文章，就把一些自己的理解，加上项目中的一些应用记在这里吧。如果有大佬看到有问题请指正。

首先解释一下那几个单词吧。

REST ：全称我把他称为资源表述性状态转移！

RE : Resource ,Representational   首先说一下什么叫做资源，你通过互联网能够请求到的东西就是一个资源，比如你的一个请求服务，你请求观看的一张图片，你看小说的txt文档，这些都是一个网络资源。 资源是一个抽象的概念，每一个资源都会有一种表述的形式可以是json，xml ，html，简单的讲就是一种资源的表现形式。

S: State 状态我理解指的就是一个http返回状态，更为具体的就是http的几种状态码，404，200,505.用这些状态码来修饰。

T:Transfer 服务器生成包含状态转移的表征数据，用来响应客户端对于一个资源的请求

REST 和REST API ：

REST 并不是一种什么技术，他是一种基于http的一种网络设计模式。RESTful API 实现了 REST规范的WEB API， 就是RESTful API客户端借助这份表征数据，记录了当前的应用状态以及对应可转移状态的方式。

RESt的url必须使用名词：

通常在设计URL时可能会根据你的url的功能加上一些动词

post /users/getUser
post /users/creatUser
post /users/updateUser
post /users/deleteUser

这是通常的一种传统请求设计，为什么会这么设计呢，url统一资源定位符，通过url来定位到一个资源，并不涉及对资源的操作，

所以操作要通过http动词来实现.

而REST是面向资源的，一般url设计会是面向一种对象的设计，比如说会定位到user的这个资源（就是这个bean）然后他的

CRUD是使用http 四种请求方式来体现的所以就不需要动词了。

get /users/{userId} 获取userId对应的user信息
post /users 创建一个新的user
put /users/{userId} 更改userId对应的user信息
delete /users/{userId} 删除userId对应的user。

REST的6大标准：

客户-服务器（Client-Server），提供服务的服务器和使用服务的客户需要被隔离对待。

无状态（Stateless），来自客户的每一个请求必须包含服务器处理该请求所需的所有信息。（有状态就是这一步的操作是在前面的操作的基础上的，无状态就是直接通过URI直接CRUD）

可缓存（Cachable），服务器必须让客户知道请求是否可以被缓存。

分层系统（Layered System），服务器和客户之间的通信必须被这样标准化。

统一接口（Uniform Interface），客户和服务器之间通信的方法必须是统一化的。

支持按需代码（Code-On-Demand，可选），服务器可以提供一些代码或者脚本

URI 和表示符：

URI定义到你当前的操作对象（资源），更细致的mapping（表示符）的是定义到每一个操作。

耦合型的网站架构：

我是做java的，java比较耦合的模式就是jsp设计，这种就是前后端耦合在一起开发。这是比较传统的

pc端设计，但是在移动互联网时代各种借口层出不穷，这种传统的mvc设计模式就很尴尬了，只能应用

pc端，但是如果Android，ios怎么办，还有微信公众号，智能手表，平板都是访问客户端，这个时候对每

一个客户端都有一套设计，这显然是不可能的。这个时候就需要解耦的方式进行设计，将前端分离出来，

这里的前端分和传统的前端又不太一样，不是简单的静态页面的设计，是指client对统一的接口进行渲染

处理。

各端的具体实现：

server端提供一套统一的API，web+android+ios作为同等公民调用同等API，一般springmvc 或者是springboot

Android：

IOS：

移动端菜鸡不做描述

web前端：

推荐随便搞！可以用重量级的AngularJS，也可以用轻量级 Backbone + jQuery