RESTful API的理解

经验 61 浏览

说到 RESTful API,大部分人心中是有那么点概念的,但是让具体说说的话,又只能说出个大概,无非就是:前后端完全分离;无状态;统一数据格式返回等。这样的理解是片面的,这样的API勉强也算是REST架构设计,但是实际上可能没有满足REST约束条件和设计原则。所以参考网上简单总结了下:

什么是REST?

REST - Representational State Transfer,即:表述性(或表现层)状态转移

由于REST是面向资源的,全称 Resource Representational State Transfer,即:资源在网络中以某种表现形式进行状态转移

Resource:资源,也就是图片、文档、视频等。我们通过URI来标识这些资源,REST是依托于HTTP协议的,HTTP的URL即资源。REST中的资源所指的不是数据,而是数据和表现形式的组合。

Representational:某种表现形式,比如用JSON,XML,JPEG等;

State Transfer:状态变化,通过HTTP动词对资源进行操作,比如GET,POST,PUT,DELETE等。

定义:REST是一种系统架构设计风格(而非标准),一种分布式系统的应用层解决方案,一组架构的约束条件和设计原则。

总结:通过URL定位资源,使用HTTP动词描述操作

什么是RESTful?

满足REST约束条件和原则的应用程序或设计就是 RESTful。

什么是RESTful API?

符合REST设计风格的API,即RESTful API。

RESTful API的基本原则?

RESTful 有六大限制,也是其基本原则。若API违反了原则,严格意义上来说就不能称为RESTful API。

| C-S架构(Client-Server

就是所谓的前后端完全分离。

优点:提高客户端的可移植性;提高服务端的拓展性;两端单独开发,互不干扰,提高了独立性。

| 无状态(Client-Stateless-Server

无状态交互意味着每次请求是独立的,无法感知和依赖另一个请求的存在。所以客户端的每次请求都要带有服务端所需的所有信息。

优点:提高了服务端的可见性(可以单独考虑每个请求);健壮性(更容易从局部故障中修复);可靠性(每次请求式独立的,无法感知和依赖另一个请求的存在);可扩展性(降低了服务器资源使用)。

缺点:由于每次都要带服务端所需的信息,造成传输数据的冗余性,网络性能降低。

| 可缓存(Client-Cachable-Stateless-Server

由于无状态架构带来的性能缺陷,我们可以通过缓存机制来解决。服务器响应必须被标记是否可以缓存,通过合理的缓存服务器响应抵消无状态架构的缺陷。

优点:减少交互次数;减少交互平均延迟;提高了性能。

| 统一接口

在基于WEB的 REST 架构风格重点强调接口的统一: 服务端需要提供标准的可见接口,保证其他系统可见,保证每个系统独立发展。其提出四点指导原则(约束):

标识资源:通过 URI 唯一标识资源。

请求动作:操作资源的方式,通过 HTTP POST、GET、...

响应信息:自描述信息,客户端请求需要告诉接受什么样的格式,是否缓存,并通过状态码表示请求结果。

超媒体:这个比较难理解!参考知乎上的解释就是:它利用 API 把所有资源的关系给链接起来了,你看到不会只是一个独立的资源,而是关系网中的一个资源。

| 分层系统

这表示组件无法了解除了与它直接交互的层次以外的组件。

优点:通过将系统知识限制在单个层,可以限制整个系统的复杂性;从而促进了底层的独立性;同时提高了可扩展性。

| 按需编码(可选)

服务端可选择临时给客户端下发一些功能代码让客户端来执行,从而定制和扩展客户端的某些功能。比如服务端可以返回一些 Javascript 代码让客户端执行,去实现某些特定的功能。

提示:RESTful原则中,只有按需编码为可选项。

优点:提高了可扩展性。

RESTful API的应用?

待补充

|  版权声明:本文为博主原创文章,转载请注明出处。

相关文章

  • 暂无相关文章