RESTful的理解
引子
大白话讲RESTful API
用URL定位资源，用HTTP描述操作
API:application programming interface 应用程序编程接口
RESTful前面的REST是什么呢？
REST就是representation state transfer表示层状态转移。首发于2000年一个博士的论文中。REST没有明确的标准，而是一种设计风格，符合REST风格的api称为RESTful API
为什么RESTful变得流行
在互联网发展初期，移动端没有现在这么百花齐放，页面请求和并发都不高。那时候使用asp，jsp的整页刷新的动态页面技术尚可。
随着互联网和移动设备的发展，人们对web应用的使用需求也增加，传统的动态页面由于整页刷新效率较低渐渐被HTML+JS（ajax）的前后端分离技术取代，且安卓，ios，微信小程序等形式客户端层出不穷，客户端种类多元化，客户端和服务端需要接口通信，而接口的规范性就成为问题
所以一套结构清晰，符合标准，易于理解，扩展方便，让大部分人能够理解接收的接口风格就显得极为重要
现在，RESTful是目前最流行的接口设计规范
RESTful API特点
-
以资源为基础：资源可以是json格式、xml、html、图片、视频。除了二进制的资源，其他更多以json为载体，面向用户的数据，一般通过数据库中查询取得 -
统一接口：对资源的操作包括获取，创建，修改和删除，这些操作正好对应http协议提供的GET、POST、PUT、DELETE方法，即使用HTTP动词表示增删改查资源
有些同学可能会说，GET、POST我也经常用啊。但是在网站里的GET和POST同RESTFul中的GET、POST是不一样的。网站里使用GET、POST的选择点在于，简单的用GET、复杂对象用POST；但在REST里，GET对应的是查询一个资源，而POST对应的是新增一个资源，意义是决然不同的。理解这一点非常重要
-
无状态：一次调用一般就会返回结果，服务器不能保存客户端的信息，每一次从客户端发送的请求中，要包含所有必须的状态信息 -
URL中只有名词：不出现动词，且推荐用复数形式
-
HTTP状态码：使用正确的HTTP Status Code表示访问状态
开始设计RESTful API
首先我们来了解一下标准的URL设计规范：
url为统一资源定位符，接口属于服务端资源，首先通过url定位到资源才能访问，通常一个完整的url由以下几部分构成
URL=scheme "://" host ":" port "/" path ["?" query]["# fragment]
- scheme：底层用的协议，如https，http，ftp
- host：服务端域名或者ip地址
- port：端口
- path：访问资源的路径
- query：查询字符串，客户端发送给服务器的参数，更多的是发送数据分页、排序参数
- fragment：锚点，定位到页面的资源
由上面可以看到，我们在设计RESTful API的时候需要考虑的重点是path部分，通常一个RESTful API的path组成如下：
/{version}/{resources}/{resource_id}
- version：API版本号，如v1，v2，v3，控制版本利于应用迭代
- resources：资源，一般为小写英文单词复数形式
- resouce_id：资源的id，访问或操作该资源
多层级资源path
/{version}/{resources}/{resource_id}/{subresources}/{subresource_id}
那么RESTful API的URL具体设计规范可以概括如下：
- api必须有version版本标志
- 使用token令牌来做用户身份校验、权限分级，而不是cookie
- 不要大写字母，所有单词使用英文小写
- 连字符用中杠
"-"，而不是下杠“_” - URL中不出现动词，用请求方式表示动作
- 资源表示用复数不用单数
- 正确使用
"/"表示层级关系，URL的层级不要过深
常用状态码
服务端处理完成后客户端可能不知道具体成功还是失败了，服务端响应时，包含状态码和返回数据两部分
状态码分类：
1xx：相关信息
2xx：操作成功
3xx：重定向
4xx：客户端错误
5xx：服务端错误
常用细分状态码：
针对不同操作，服务器向用户返回数据，而各个团队或公司封装的返回实体类也不同，但都返回JSON格式数据给客户端
RESTful API案例
如用户场景
非RESTful
获取用户：/users/query/{userid}
插入用户：/users/add
更新用户：/users/update/{userid}
删除用户：/users/delete/{userid}
RESTful版本
GET: /users/{userid}
POST: /users
PUT: /users/{userid}
DELETE:/users/{userid}
使用postman进行发送请求的时候，有三种常用的文件类型传递到后端：
RESTful API缺点
RESTful风格的API 固然很好很规范，但大多数互联网公司并没有按照或者完全按照其规则来设计，因为REST是一种风格，而不是一种约束或规则，过于理想的RESTful API 会付出太多的成本
缺点：
- 操作方式繁琐，RESTful API通常根据GET、POST、PUT、DELETE 来区分操作资源的动作，而HTTP Method 本身不可直接见，是隐藏的，而如果将动作放到URL的path上反而清晰可见，更利于团队的理解和交流
- 并且有些浏览器对GET,POST之外的请求支持不太友好，还需要特殊额外的处理
- 过分强调资源，而实际业务API可能有各种需求比较复杂，单单使用资源的增删改查可能并不能有效满足使用需求，强行使用RESTful风格API只会增加开发难度和成本
所以，当你或你们的技术团队在设计API的时候，如果使用场景和REST风格很匹配，那么你们可以采用RESTful 风格API。但是如果业务需求和RESTful风格API不太匹配或者很麻烦，那也可以不用RESTful风格API或者可以借鉴一下，毕竟无论那种风格的API都是为了方便团队开发、协商以及管理，不能墨守成规
