架构特征

以资源为基础

​ 资源可以是一张图片、音乐、一个XML格式、HTML格式或者JSON格式等网络上的一个实体，除了一些二进制的资源外普通的文本资源更多以JSON为载体、面向用户的一组数据(通常从数据库中查询而得到)。

统一接口

​ 对资源的操作包括获取、创建、修改、和删除，这些操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法。换言之，使用restful风格的接口单从接口上你可能职能定位其资源，但无法知晓其具体进行了什么操作，需要具体了解发生了什么操作要从其HTTP请求方法类型上进行判断。具体的HTTP方法和犯法含义如下：

GET（SELECT）：从服务器取出资源（一项或多项）。
POST（CREATE）：在服务器新建一个资源。
PUT（UPDATE）：在服务器更新资源（客户端提供完整资源数据）。
PATCH（UPDATE）：在服务器更新资源（客户端提供需要修改的资源数据）。
DELETE（DELETE）：从服务器删除资源。

​ 从请求的流程来看，restful和传统的APL大致构架如下：

URL指向资源

​ URI = Universal Resource identifier(统一资源标志符)，用来标识抽象或物理资源的一个紧凑字符串。URL包括URL和URN，在这里更多时候可能代指URL(统一资源定位符)。restful是面向资源的，每一种资源可能由一个或者多个URI对应，但一个URI只指向一种资源。

无状态

​ 服务器不能保存客户端的信息，每一次从客户端发送的请求中，要包含所有必须的状态信息，会话信息由客户端保存，服务器端根据这些状态信息来处理请求，当客户端可以切换到一个新状态的时候发送请求信息，当一个或者多个请求被发送之后，客户端就处于一个状态变迁过程中。每一个应用的状态描述可以被客户端用来初始化下一次的状态变迁。

rest架构限制条件

标准的rest约束应满足一下6个原则：

客户端-服务端（Client-Server）: 这个更专注客户端和服务端的分离，服务端独立可更好服务于前端、安卓、IOS等客户端设备。
无状态（Stateless）：服务端不保存客户端状态，客户端保存状态信息每次请求携带状态信息。
可缓存性（Cacheability） ：服务端需回复是否可以缓存以让客户端甄别是否缓存提高效率。
统一接口（Uniform Interface）：通过一定原则设计接口降低耦合，简化系统架构，这是RESTful设计的基本出发点。当然这个内容除了上述特点提到部分具体内容比较多详细了解可以参考这篇REST论文内容。
分层系统（Layered System）：客户端无法直接知道连接的到终端还是中间设备，分层允许你灵活的部署服务端项目。
按需代码（Code-On-Demand，可选）：按需代码允许我们灵活的发送一些看似特殊的代码给客户端例如JavaScript代码。

restful API 设计规范

URL设计规范

URL为统一资源定位器 ,接口属于服务端资源，首先要通过URL这个定位到资源才能去访问，而通常一个完整的URL组成由以下几个部分构成：

URI = scheme "://" host  ":"  port "/" path [ "?" query ][ "#" fragment ]

scheme: 指底层用的协议，如http、https、ftp

host: 服务器的IP地址或者域名

port: 端口，http默认为80端口

path: 访问资源的路径，就是各种web 框架中定义的route路由

query: 查询字符串，为发送给服务器的参数，在这里更多发送数据分页、排序等参数。

fragment: 锚点，定位到页面的资源

我们在设计API时URL的path是需要认真考虑的，而RESTful对path的设计做了一些规范，通常一个RESTful API的path组成如下：

/{version}/{resources}/{resource_id}

version：API版本号，有些版本号放置在头信息中也可以，通过控制版本号有利于应用迭代。

resources：资源，RESTful API推荐用小写英文单词的复数形式。

resource_id：资源的id，访问或操作该资源。

有时候可能资源级别较大，其下还可细分很多子资源也可以灵活设计URL的path，例如：

/{version}/{resources}/{resource_id}/{subresources}/{subresource_id}

有时可能增删改查无法满足业务要求，可以在URL末尾加上action，例如：

/{version}/{resources}/{resource_id}/action

其中action就是对资源的操作。

从大体样式了解URL路径组成后，对于restful APL的URL具体设计的规范如下：

1.不用大写字母，所有单词使用英文且小写。
2.连字符用中杠"-"而不用下杠"_"
3.正确使用 "/"表示层级关系,URL的层级不要过深，并且越靠前的层级应该相对越稳定
4.结尾不要包含正斜杠分隔符"/"
5.URL中不出现动词，用请求方式表示动作
6.资源表示用复数不要用单数
7.不要使用文件扩展名

HTTP动词

在非restful API中，不同的HTTP请求方法有各自的含义。针对不同操作，具体含义如下：

GET /collection：从服务器查询资源的列表（数组）
GET /collection/resource：从服务器查询单个资源
POST /collection：在服务器创建新的资源
PUT /collection/resource：更新服务器资源
DELETE /collection/resource：从服务器删除资源

在非restful风格的API中，我们通常使用GET请求和POST请求完成增删改查以及其他操作，查询和删除一般使用GET方式请求，更新和插入一般使用POST请求。从请求方式上无法知道API是干嘛的，素有在URL上都会有操作的动词来表示API进行的动作，例如：query，add，update，delete等等。

而restful风格的API则要求在URL上都以名词的方式出现，从几种请求方式上就可以看出想要进行的操作，这点与非restful风格的API形成鲜明对比。

在谈及GET，POST，DELETE的时候，就必须提一下接口的安全性和幂等性。

安全性是指：方法不会修改资源状态，朗读的为安全的，写的操作为非安全的。

幂等性是指：操作一次和操作多次的最终效果相同，客户端重复调用耶只返回同一个结果。

上述四个HTTP请求方法的安全性和幂等性如下：

状态码和返回数据

服务端处理完成后客户端也可能不知道具体成功还是失败了，服务器响应时，包含状态码和返回数据两部分

状态码：

首先要正确使用各类状态码来表示请求的处理执行结果。状态码分五大类：

1xx：相关信息
2xx：操作成功
3xx：重定向
4xx：客户端错误
5xx：服务器错误		

每一大类有若干小类，状态码的种类比较多;

状态码	说明
200	（成功）服务器已成功处理了请求。
201	（已创建）请求成功并且服务器创建了新的资源。
204	（无内容）服务器成功处理了请求，但没有返回任何内容。
301	（永久移动）请求的网页已永久移动到新位置。
302	（临时移动）服务器目前从不同的位置响应请求。
400	（错误请求）服务器不理解请求的语法。
401	（未授权）请求要求身份验证。
403	（禁止）无权限, 服务器拒绝请求。
404	（未找到） 服务器找不到请求的资源
408	（超时） 请求超时
422	（验证错误） 请求参数未通过验证
429	（被限制）请求次数过多
500	（服务器内部错误） 服务器遇到错误，无法完成请求。
501	（尚未实施） 服务器不具备完成请求的功能。
502	（错误网关） 服务器作为网关或代理，从上游服务器收到无效响应。
503	（服务不可用） 服务器目前无法使用（由于超载或停机维护）。 通常，这只是暂时状态。
504	（网关超时） 服务器作为网关或代理，但是没有及时从上游服务器收到请求。
505	（HTTP 版本不受支持） 服务器不支持请求中所用的 HTTP 协议版本。

restful APL缺点

• 操作方式繁琐，RESTful API通常根据GET、POST、PUT、DELETE 来区分操作资源的动作，而HTTP Method 本身不可直接见，是隐藏的，而如果将动作放到URL的path上反而清晰可见，更利于团队的理解和交流。
• 并且有些浏览器对GET,POST之外的请求支持不太友好，还需要特殊额外的处理。
• 过分强调资源，而实际业务API可能有各种需求比较复杂，单单使用资源的增删改查可能并不能有效满足使用需求，强行使用RESTful风格API只会增加开发难度和成本。