REST、RESTFUL的理解以及SpringMVC实现Restful编程

其实HTTP 1.1协议的整体软件架构就可以说是REST架构

了解REST得知道5个名字：

1、资源 Resource

资源就是服务器上获取到的东西都可以说是资源，一条用户记录，一个用户的密码，一张图片等等都是

2、资源的表述 Representation

就是资源的格式，是HTML、XML、JSON、纯文本、图片等等，可以用各种各样的格式来表述你获取到的资源，这就是资源的表述

3、状态转移 State Transfer

URL定位资源，用HTTP动词（GET,POST,DELETE,DETC）描述操作。操作是动词，资源是名词

4、统一接口 Uniform Interface

REST必须通过统一的接口对资源进行操作，HTTP1.1协议定义了资源的统一接口：

·GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS

`HTTP  HEAD可以自定义

·HTTP STATUS响应状态 可自定义

·一套标准的内容协商机制

·一套标准的缓存机制

·一套标准的客户端身份认证机制

5、超文本驱动 Hypertext Driven

资源之间通过超链接相互关联，超链接代表资源之间的关系，也代表可执行的状态迁移

Restful API就是按照REST架构的思想设计出来的API

核心就是：将API拆分为逻辑上的资源，这些资源通过http（GET/POST/PUT/DELETE等）被操作

SpringMVC的 Restful API

这里就是个简单的例子，URL中tests表示资源，使用GET方法操作，得到资源对象，这里除了GET以外的HTTP方法是404的结果

从以上实例想想，其实挺合理的，这么丰富的HTTP方法，我们干嘛还通过我们的自定义url来定义各种操作呢！！

有人说Restful API最好做到Hypermedia，超媒体，即返回结果提供链接，对应下一步的API，即使用户不查文档，也知道下一步该做什么，不过个人觉得，不是刚需，或者我还没遇到这种需求。github就是这样的

上面的实例是最基本的API设计了，有个很明显的缺陷，就是API升级时会遇到问题，因为没有版本的概念，导致服务端升级的话，所有使用的人都受到影响，但是往往实际中，有些用户可能对新版本的API不太需要，仍然想沿用旧的，那么唯一的办法就是部署两套服务端，一个旧的，一个新的，显然成本太高了。

所以需要在API中引入版本的概念

将版本号作为API的URL中的一个资源来设计

将来如果升级版本了，你可以通过在代码中新增一个else分支即可，原本的版本号的API该怎样继续保持不动，新的版本的逻辑新增代码即可，这样可以继续支持旧版本，将来可以通过监控来检测旧版本的使用率，做到平滑过渡，慢慢废弃旧版本。