前后端分离中的Rest&Restful架构

----最近在接触spring cloud的时候，经常会看见Rest&Restful的字眼，又对这两个词完全没有印象，于是去了解了下，现在我们从传统API的缺点开始讲起

传统API接口

以我的观点，应用是以数据为逻辑中心的，对于数据的操作不外乎增删改查四种。http协议针对这四种操作分别提供了POST、DELETE，PUT、GET四种方法，简单优雅。但是我们以往在写服务端API的时候，往往会用GET和POST解决一切，背离http协议设计的初衷。更窒息的是，混乱还不仅仅如此。
URL代表着统一资源唯一定位符，是名词性质的，不应该带有任何动作。但是由于对http协议的错误理解，我们往往会在其中混入动词。
比如：当我们对学生对象进行删除操作时可能会有以下写法：

	GET: http://***/student/delete?id=xxx
	GET: http://***/student/deletebyid/{id}
	GET: http://***/student/{id}/delete

这仅仅是简单的删除的操作，却有了如此多的书写风格，在规范严格的公司里或许还能依靠规范实现风格的统一。但是当人员流动加大，服务提供商变多时，对API的调用则显得混乱了

关于Rest和Restful的概述

Rest的全程是Representational State Transfer，表征性状态转移，是一组架构约束条件和原则。我认为可以理解成一种规范
满足Rest规范的架构即可被称作Restful架构

Rest的特点

无状态

这个含义是服务器不需要知道客户端现在处于什么状态，客户端也不必知道服务器是什么状态。这意味着即使没看到以前的消息，也不影响双方对本次通信的理解。
在web项目里可以理解为，服务端没有保存任何浏览器的状态信息，浏览器发送的任何请求必须要确保足够服务端使用。
比如说：登陆状态的保存，不能依靠服务器去记忆每个浏览器对应的用户而应该用加密的方式把用户签名保存在浏览器中，在向服务器发送请求时，附加上用户签名，让服务器校验。

面向资源/对象

符合Rest规范的API，在前后端通信时，URI仅仅用于标记资源。仅仅作为名词形式。
比如：

	在A市下新增C企业：PUSH IP:Port/citys/A/companys/C
	删除A市下的C企业:   DELETE IP:Port/citys/A/Companys/C
	更改A市C企业的名字为B：PUT IP:Port/citys/A/Companys/C/name/B
	查询A市下C企业的相关信息：GET IP:Port/citys/A/Companys/C