简述REST与RESTFUL--简单明了一看就懂

概述
今天在学校和同事讨论新项目开发的各种问题，顺便问了一个资历比较老的老师一个问题，就是什么是rest和restful，简单几句话打开了我对rest使用的各种疑虑，索性将这一个知识缺口整理成随笔记录在博客中，希望后来人能够通过这一篇博文，解决你对rest和restful使用过程中的各种问题。尤其是入门级别的小白们，千万不要给我说，懂的不用看，不懂的也不用看；）

问题概述
对于REST和RESTFUL我们从以下几个问题进行阐述：

1. 什么是REST？什么是RESTFUL？
2. 为什么要使用REST和RESTFUL？
3. 如何使用RESTFUL做网络接口api
4. 目前使用这种模式的问题还有哪些？

什么是REST

官方解释，网络资源的解释原意是：REST= representational state transfer 表述性状态转移。显然，直接翻译的结果根本不是人能看懂的，而作为对其进行理解我个人认为也无需对其解释中的各种名词作详细解释，我们只要知道REST是一种HTTP协议使用过程中遵循的设计风格，是一种使用格式，称之为规范也不为过。个人感觉类似于做饭，都是白菜，为什么做出来分粤菜，鲁菜，川菜，那是因为不同的使用格式确定了最终的习惯和结果。

什么是RESTFUL？
RESTFUL从英文原意上就是REST+FUL，意思就是“遵循REST风格使用的“，换句话将只要是遵循REST使用的各种技术，各种接口定义，各种api都可以称之为RESTFUL。

为什么要使用这种风格
这个问题就要谈谈HTTP协议的创始人Roy T. Fielding,在2000年，它发表了一篇关于软件架构设计风格相关的论文，文中对http的各种使用情况做出了架构风格级别的指导和推荐，这就是REST。原因是作者发现人们在使用HTTP协议时对于他设计的这种协议使用初衷有很大的误区，大家在使用URL的地址设计时，往往都在使用动词添加在URL地址中，例如：http://www.school.com/user1/getUserId ， 请求方式get。在这个举例中，对于URL使用的定位就违反了REST风格的设计定义。作者认为URL应该只用作定位一个网络的资源，任何URL地址的不同都指向了网络一个唯一的资源标识，对于资源的具体操作，不要忘了HTTP协议提供的多种方法访问，PUT表示更新，POST表示新增（或者两者反之），GET表示查询，DELETE表示删除，但是长期的使用中，人们习惯于使用GET完成不同的方式调用，只需要对URL地址进行任意的修改，甚至使用动词，就像例子中这个“getUserId”的地址，实际上按照HTTP的设计初衷，URL只能定义名词的资源位置，而使用不同的调用方式完成对资源不同的动作处理， 而这片论文的出现，实际意图也是作者强调了HTTP协议设计的初衷。而作何的意图和初衷恰恰满足了15年后微服务开发的需求，就是REST的风格提供了微服务中各种接口的设计模式，设计规范。使得微服务在这种访问模式下顺风顺水的进行下去。

如何使用RESTFUL设计接口
使用RESTFUL设计接口API的过程非常简单，我们就以对某个网络资源中的user数据进行操作为例：

• GET http://www.shcool.com/user/id ; 获取user
• POST http://www.school.com/user/id ;新增user
• PUT http://www.school.com/user/id ; 修改user
• DELETE http://www.school.com/user/id; 删除user

目前使用这种模式的问题还有哪些？
随着微服务的兴起，壮大，同一个系统中不同资源的访问需求变得越来越复杂，复杂到对资源的调用绝不简简单单停留在CRUD，利用在注册时，我们需要判断的是用户资源，但是用户资源存不存在是通过手机号或者用户名判断的，这时CRUD应该是使用查询操作，但是资源都是用户，在用户中心进行查询也需要定位同一个资源数据进行查询，这样两种方式就冲突了。不可能存在同一个资源地址都是查询，却返回不同的结果，这也是REST使用的一个弊端，使用REST必定导致URL设计的复杂，在这种情况下，有时候在资源URL地址固定格式设计下，使用域名/版本/资源/必要的动词描述，可以有效的区分开这种访问。

结语
对于一项规范，风格的使用，我们需要尊重他的便利和有效的特点，但既然是规范，如果存在不方便的一些缺点，一定要敢于尝试更改，随着技术发展，也可能有一天，REST风格的设计将会被某种其他的规范取代。