开发篇:REST API介绍以及工作原理

Blog链接:https://blog.51cto.com/13969817

要理解什么是REST API 以及它是如何工作的?

首先要理解REST是Representational State Transfer 的缩写,简单地说它是Web应用程序或者移动应用程序、或者智能手表、或者任何使用数据访问的接口。

当客户端提交请求时,在这种情况下得到一个资源,REST API 接收该请求,标识所请求的资源,找出哪些数据需要聚集、什么格式、数据匹配的创建一个表示请求的格式,包括像resource ID、指向可用动作的Hyperlinks 等,回应多媒体格式的响应发送,并将其发送回客户端。客户端接收数据并将其解析为有意义的内容,而REST API则等待下一个请求。

简单而言,客户端发出请求,REST API 接收请求、收集和解析数据,并将数据和响应标头返回给客户端。

为了更好的理解REST,我们先来分解一下REST的6个约束条件:

1.Client-Server架构,这个约束确保了客户端管理用户界面,而服务器端管理数据存储,简而言之,我们将内容与它的交互完全分离。

  1. 无状态性,在请求之间,补鞥呢在服务器上存储客户端上下文或者信息(即状态),客户端负责跟踪自己的会话状态,从客户端发送的所有请求必须是自包含和完整的,如果客户端的会话状态是相关的,则必须将其请求一起发送,如果服务器需要存储该状态,则必须在特定时间将其传递到数据库或者类似服务。
  2. 可缓存性,缓存是Web体系结构和性能优化的关键部分,所有REST响应必须被清楚地标记为可缓存或者不可缓存,以确保缓存在客户端按预期工作。
  3. 分层系统,系统必须设计成客户端不能知道它是直接连接到服务器还是连接到镜像等中介,这样可以确保可伸缩性,也有助于安全性。
  4. 按需编码,允许服务器以客户端JavaScript和已编译组件的形式向客户端传输可执行的代码,以扩展和自定义功能,这是REST不太常见的用法。
  5. 统一接口,必须在请求中使用资源标识,在Web上的REST系统中,URI用于发送请求,该URI将指定它要查找的资源,这里的关键是服务器上的数据,REST 返回的是该资源的一种表现,它可以具有与服务器资源不同的格式,所以,虽然资源数据可以作为表存储在我的SQL中,但返回可能是JSON或者XML设置HTML,接下来,一旦客户端拥有了资源的表示,它还可以修改或者删除该资源。第三,统一接口必须发布描述信息,这适用于发送和接收REST数据,如果接收JSON,则响应信息的媒体类型将设置为JSON,没有这些信息,就无法可靠地解析数据。第四,统一接口必须使用超媒体作为应用状态的引擎,这是一种复杂的说法,一旦客户端访问REST资源,它就能够通过提高的超链接发现所有可用的资源和方法。

换句话说,REST服务描述了它自己对每个返回资源的使用,当且仅当基于Web的API满足这6个约束时,就可以认为它是RESTful API。

现在我们将从一个基本的Get请求开始,一个Application/json格式体的例子如下:

{
"<name>": "<value>"
}

样例:如果你想使用类似下方的请求头字段为Azure Resource Manager provider 发送一个Https get的请求方法

GET /subscriptions?api-version=2014-04-01-preview HTTP/1.1
Authorization: Bearer <bearer-token>
Host: management.azure.com

更多关于处理响应信息或者同步、Throttling等等信息请访问:https://docs.microsoft.com/en-us/rest/api/azure/