RESTful及其特点

什么是RESTful

REST（Resource Representational State Transfer）是Roy Thomas Fielding在他2000年的博士论文中提出的。如果一个架构符合REST原则，就称为RESTful架构，是一种面向资源的软件架构风格
。

REST即Representational State Transfer的缩写，可译为"表现层状态转化”。REST最大的几个特点为：资源、统一接口、URI和无状态。

如何设计RESTful

1. 域名：
   将api部署在专用域名下：http://api.example.com
   或者将api放在主域名下：http://www.example.com/api/

2. 版本
   将API的版本号放在url中：http://www.example.com/api/v1.0

3. 路径
   路径表示API的具体网址。每个网址代表一种资源。 资源作为网址，网址中不能有动词只能有名词，一般名词要与数据库的表名对应。而且名词要使用复数。
   正确示例： http://www.example.com/api/v1.0/goods
   错误示例： http://www.example.com/app/getgoods # 包含动词

4. 状态码（前后端分离的开发都要用到状态码）
   服务器向用户返回的状态码和提示信息，常用的有：
   200 OK ：服务器成功返回用户请求的数据
   201 CREATED ：用户新建或修改数据成功。
   202 Accepted：表示请求已进入后台排队。
   400 INVALID REQUEST ：用户发出的请求有错误。
   401 Unauthorized ：用户没有权限。
   403 Forbidden ：访问被禁止。
   404 NOT FOUND ：请求针对的是不存在的记录。
   406 Not Acceptable ：用户请求的的格式不正确。
   500 INTERNAL SERVER ERROR ：服务器发生错误。

5. 自定义错误信息
   一般来说，服务器返回的错误信息，以键值对的形式返回。
   {
   error:‘Invalid API KEY’
   }

6. 响应结果
   服务器返回的数据格式，应该尽量使用JSON

特点

1. 资源：网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。资源总要通过某种载体反应其内容，文本可以用txt格式表现，也可以用HTML格式、XML格式表现，甚至可以采用二进制格式；图片可以用JPG格式表现，也可以用PNG格式表现；JSON是现在最常用的资源表示格式。

网络上的实体！

2. 统一接口：数据的元操作，即CRUD(create, read, update和delete,即数据的增删查改)操作，分别对应于HTTP方法：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源，这样就统一了数据操作的接口，仅通过HTTP方法，就可以完成对数据的所有增删查改工作。

通过HTTP方法来确定并完成对实体的操作！

3. URI：可以用一个URI（Universal Resource Identifier，统一资源定位符）指向资源，即每个URI都对应一个特定的资源。要获取这个资源，访问它的URI就可以，因此URI就成了每一个资源的地址或识别符。一般的，每个资源至少有一个URI与之对应，最典型的URI即URL。

通过URI来识别不同的资源（实体）！

4. 无状态：所有的资源，都可以通过URI定位，而且这个定位与其他资源无关，也不会因为其他资源的变化而改变。

• WebSocket是有状态的

通过URI对资源（实体）操作时，无状态，没有上下文的影响！

URI = Universal Resource Identifier统一资源标识符
URL = Universal Resource Locator统一资源定位符
URN = Uniform Resource Name统一资源名称

URI属于父类，而URL属于URI的子类。URL是URI的一个子集。
URI表示请求服务器的路径，定义这么一个资源。
URL同时说明要如何访问这个资源（http://）。

URL 的格式由下列三部分组成 :
第一部分是协议 ( 或称为服务方式 );
第二部分是存有该资源的主机 IP 地址 ( 有时也包括端口号 );
第三部分是主机资源的具体地址。
URI 一般由三部分组成 :
访问资源的命名机制。
存放资源的主机名。
资源自身的名称，由路径表示

优点

1. pc/app/pad 多端适应
2. SPA开发模式的开始流行（SPA：单页Web应用（single page web application，SPA））
3. 前后端基本完全独立
4. 无状态，在调用接口时，不需要考虑上下文流程或者状态
5. 简单、低耦合
6. 是典型的ROA（Resource Oriented Architecture）架构

缺点

1. 前后端学习门槛增加（前端要处理的数据变多了，后端传递数据要满足新的接口规范）
2. 数据依赖导致文档重要性增加
3. 前端工作量加大
4. SEO的难度加大(SEO：搜索引擎优化（Search Engine Optimization）)

总结

web service早期为RPC(remote procedure call)，后来渐渐被SOAP协议（简单对象访问协议（Simple Object Access Protocol））取代，而RESTful API（也称RESTful Web服务）逐渐超越SOAP成为实现SOA（Service Oriented Ambiguity）的重要手段之一。

本真REST与hybrid风格

通常开发者做服务相关的客户端开发时，使用的所谓RESTful服务，基本可分为本真REST和hybrid风格两类。本真REST即我上文阐述的RESTful架构风格，具有上述的4个特点，是真正意义上的RESTful风格；而hybrid风格，只是借鉴了RESTful的一些优点，具有一部分RESTful的特点，但对外依然宣称是RESTful风格的服务。（窃以为，正是由于hybrid风格服务混淆了RESTful的概念，才在RESTful架构风格提出了本真REST的概念，以为了划分界限 ?）
hybrid风格的最主流的用法是，使用GET方法获取资源，用POST方法实现资源的创建、修改和删除。hybrid风格之所以存在，据我了解有两种来源：一种情况是因为，某些开发者并没有真正理解何为RESTful架构风格，导致开发的服务貌合神离；而主流的原因是由于历史包袱 —— 服务本来是RPC风格的，由于上文提到的RPC的劣势及RESTful的优势，开发者在RPC风格的服务上又包装了一层RESTful的外壳，通常这层外壳只为获取资源服务，因此会按RESTful风格实现GET方法，如果客户端提出一些简单的创建、修改或删除数据的需求，则通过HTTP协议中最常用的POST方法实现相应功能。
因此，开发RESTful 服务，如果没有历史包袱，不建议使用hybrid风格。

权限认证

由于RESTful风格的服务是无状态的，认证机制尤为重要。

• 认证机制解决的问题是，确定访问资源的用户是谁；认证机制基本上是通用的，本真REST + OAuth是RESTful 是微服务的标配。
• 权限机制解决的问题是，确定用户是否被许可使用、修改、删除或创建资源。权限机制通常与服务的业务逻辑绑定，因此权限机制需要在每个系统内部定制。