RESTful及其特点
什么是RESTful
REST(Resource Representational State Transfer)是Roy Thomas Fielding在他2000年的博士论文中提出的。如果一个架构符合REST原则,就称为RESTful架构,是一种面向资源的软件架构风格
。
REST即Representational State Transfer的缩写,可译为"表现层状态转化”。REST最大的几个特点为:资源、统一接口、URI和无状态。
如何设计RESTful
-
域名:
将api部署在专用域名下:http://api.example.com
或者将api放在主域名下:http://www.example.com/api/ -
版本
将API的版本号放在url中:http://www.example.com/api/v1.0 -
路径
路径表示API的具体网址。每个网址代表一种资源。 资源作为网址,网址中不能有动词只能有名词,一般名词要与数据库的表名对应。而且名词要使用复数。
正确示例: http://www.example.com/api/v1.0/goods
错误示例: http://www.example.com/app/getgoods # 包含动词 -
状态码(前后端分离的开发都要用到状态码)
服务器向用户返回的状态码和提示信息,常用的有:
200 OK :服务器成功返回用户请求的数据
201 CREATED :用户新建或修改数据成功。
202 Accepted:表示请求已进入后台排队。
400 INVALID REQUEST :用户发出的请求有错误。
401 Unauthorized :用户没有权限。
403 Forbidden :访问被禁止。
404 NOT FOUND :请求针对的是不存在的记录。
406 Not Acceptable :用户请求的的格式不正确。
500 INTERNAL SERVER ERROR :服务器发生错误。 -
自定义错误信息
一般来说,服务器返回的错误信息,以键值对的形式返回。
{
error:‘Invalid API KEY’
} -
响应结果
服务器返回的数据格式,应该尽量使用JSON
特点
- 资源:网络上的一个实体,或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务,总之就是一个具体的实在。资源总要通过某种载体反应其内容,文本可以用txt格式表现,也可以用HTML格式、XML格式表现,甚至可以采用二进制格式;图片可以用JPG格式表现,也可以用PNG格式表现;JSON是现在最常用的资源表示格式。
网络上的实体!
- 统一接口:数据的元操作,即CRUD(create, read, update和delete,即数据的增删查改)操作,分别对应于HTTP方法:GET用来获取资源,POST用来新建资源(也可以用于更新资源),PUT用来更新资源,DELETE用来删除资源,这样就统一了数据操作的接口,仅通过HTTP方法,就可以完成对数据的所有增删查改工作。
通过HTTP方法来确定并完成对实体的操作!
- URI:可以用一个URI(Universal Resource Identifier,统一资源定位符)指向资源,即每个URI都对应一个特定的资源。要获取这个资源,访问它的URI就可以,因此URI就成了每一个资源的地址或识别符。一般的,每个资源至少有一个URI与之对应,最典型的URI即URL。
通过URI来识别不同的资源(实体)!
- 无状态:所有的资源,都可以通过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 一般由三部分组成 :
访问资源的命名机制。
存放资源的主机名。
资源自身的名称,由路径表示
优点
- pc/app/pad 多端适应
- SPA开发模式的开始流行(SPA:单页Web应用(single page web application,SPA))
- 前后端基本完全独立
- 无状态,在调用接口时,不需要考虑上下文流程或者状态
- 简单、低耦合
- 是典型的ROA(Resource Oriented Architecture)架构
缺点
- 前后端学习门槛增加(前端要处理的数据变多了,后端传递数据要满足新的接口规范)
- 数据依赖导致文档重要性增加
- 前端工作量加大
- 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 是微服务的标配。
- 权限机制解决的问题是,确定用户是否被许可使用、修改、删除或创建资源。权限机制通常与服务的业务逻辑绑定,因此权限机制需要在每个系统内部定制。