[ad_1]
什么是休息？
REST 首字母缩写词被定义为“REpresentational State Transfer”，旨在在用于 Web API 时利用现有的 HTTP 协议。 它非常灵活，因为它不依赖于资源或方法，并且能够处理不同的调用和数据格式。 由于 REST API 不受 SOAP 等 XML 格式的限制，因此它可以根据需要返回多种其他格式。 如果服务遵循这种风格，则它被视为“RESTful”应用程序。 REST 允许组件访问和管理另一个应用程序中的功能。
REST 最初是在 Roy Fielding 二十年前的一篇论文中定义的。 他提出这些标准作为 SOAP 的替代方案（简单对象访问协议是一种用于在分布式计算环境中访问对象和交换结构化消息的简单标准）。 REST（或 RESTful）定义了用于规范 Web 应用程序之间交互的通用规则，这些规则利用 HTTP 协议进行 CRUD（创建、检索、更新、删除）操作。
什么是 API？
API（或应用程序编程接口）提供了两个系统之间交互的方法。
什么是 RESTful API？
RESTful API（或应用程序接口）使用 HTTP 请求来遵循 REST 标准来获取、放置、发布和删除数据。 这允许两个软件相互通信。 本质上，REST API 是一组使用标准方法以特定格式返回数据的远程调用。
以这种方式交互的系统可能非常不同。 每个应用程序可能使用独特的编程语言、操作系统、数据库等。那么，我们如何创建一个可以轻松沟通和理解其他应用程序的系统？ 这就是 Rest API 用作交互系统的地方。
在使用 RESTful API 时，我们应该提前确定要向外界公开哪些资源。 通常，实现 RESTful API 服务时，牢记以下想法：
- 格式：数据交换格式应该没有限制
- 实现：REST 完全基于 HTTP
- 服务定义：因为 REST 非常灵活，可以修改 API 以确保应用程序理解请求/响应格式。
- RESTful API 侧重于资源以及您使用 HTTP 对其执行操作的效率。
REST API 设计风格状态的特点：
- 每个实体都必须有一个唯一的标识符。
- 应该使用标准方法来读取和修改数据。
- 它应该为不同类型的资源提供支持。
- 交互应该是无状态的。
为了让 REST 适合这个模型，我们必须遵守以下规则：
- 客户端-服务器架构：接口与服务器端数据存储库是分开的。 这提供了灵活性和相互独立的组件开发。
- 分离：客户端连接不存储在请求之间的服务器上。
- 可缓存性：必须明确说明客户端是否可以存储响应。
- 多级：无论是直接与服务器交互还是通过附加层（如负载均衡器）交互，API 都应该有效。
HTTP 组件
这里有两个主要组成部分。 HTTP 请求结构和 HTTP 响应结构。
HTTP 请求结构具有以下属性：
- 请求行——这定义了消息的类型。
- 报头字段——这些字段定义了消息正文、传输参数和其他信息。
- Body – 请求正文，可选。
HTTP 响应结构具有以下属性：
- 状态行 – 提供状态代码。
- 标头字段 – 显示标头响应字段。
- 正文 – 可选的消息正文。
与服务器的所有交互都归结为四个基本操作：
（四个是最小值，但在其他实现中，可以有更多）。
- 从服务器接收数据（通常是 JSON 或 XML 格式）。
- 向服务器添加新数据。
- 修改服务器上的基本数据。
- 删除服务器上的数据。
如上所述，还存在 CRUD 操作概念。 CRUD 是用于处理数据时使用的四个基本功能的首字母缩写词：
- 创建
- 读
- 更新
- 删除
CRUD 概念由 James Martin 于 1983 年引入，作为数据操作的标准分类。 为了执行这些操作，使用了各种 HTTP 请求方法。
- GET – 获取有关资源的详细信息。
- POST – post 创建一个新资源。
- PUT – put 更新现有资源。
- DELETE – 删除删除现有资源。
HTTP 状态代码
以前，当使用这些方法之一发出这些请求之一时，我们可能会遇到错误并且根本没有得到响应。 为了解决这个问题，设计了 HTTP 状态码。
1xx：信息
- 100：继续
2xx：成功
- 200：好的
- 201：创建
- 202：接受
- 204：无内容
3xx：重定向
- 301：永久移动
- 307：临时重定向
4xx：客户端错误
- 400：错误请求
- 401：未经授权
- 403：禁止
- 404：未找到
5xx 服务器错误
- 500内部服务器错误
- 501：未实施
- 502错误的网关
- 503服务不可用
- 504网关超时
您可能已经不止一次遇到过其中一些错误，尤其是非常流行的 404 错误。
获取
现在，让我们看一个使用方法创建 Rest API 服务的示例。
我们使用 HTTP GET 来获取（或读取）资源的表示。 如果成功接收到地址（无错误），GET 将返回一个 JSON 或 XML 表示以及 HTTP 状态代码 200（OK）。 如果出现错误，通常会返回代码 404（未找到）或 400（错误请求）。
- 获取 https://www.example.com/api/v1.0/users
（返回用户列表） - 获取 https://www.example.com/api/v1.0/users/ellen
（返回id 为ellen 的用户信息） - 获取 https://www.example.com/api/v1.0/users/12345/orders
（返回 id 为 ellen 的用户订单列表）
HTTP PUT
HTTP PUT 通常用于提供更新资源的能力。 如果 PUT 请求成功，则返回代码 200（如果没有为更新提供值，则返回 204）。 值得注意的是，PUT 请求是不安全的，因为它修改了服务器端的资源。 但是通过使用PUT方式发送数据，数据不会消失，会定位到之前的位置，重复执行PUT请求不会改变系统的总体状态。
- PUT https://www.example.com/api/v1.0/users/ellen
（用 id ellen 更新用户数据） - PUT https://www.example.com/api/v1.0/users/ellen/orders/12345
（为 id 为 ellen 的用户更新 id 为 12345 的订单数据）
HTTP POST
HTTP POST 请求最常用于创建新资源。 传统上，它用于创建嵌套资源。 换句话说，在创建新资源时，会向父资源发送 POST 请求。 因此，服务负责并建立已创建资源与父资源的连接，为新资源分配一个 ID，等等。成功创建后，HTTP 代码 201（如果系统正在运行后台任务，则可能是代码 202）实际创建请求的对象）被返回，并且创建的资源的地址也在’Location’头中传输。
发布 https://www.example.com/api/v1.0/customers
（在客户部分创建一个新资源）
发布 https://www.example.com/api/v1.0/customers/ellen/orders
（为 ID 为 ellen 的资源创建订单）
HTTP 删除
HTTP DELETE 用于删除具有特定 id 的资源。 成功删除后，将返回状态 200 (OK)。 也可以在没有响应正文的情况下使用状态 204（NO CONTENT）。
- 删除 https://www.example.com/api/v1.0/customers/ellen
（从客户中删除 id 为 ellen 的资源） - DELETE https://www.example.com/api/v1.0/customers/ellen/orders/10（从id为ellen的资源中删除id为10的订单）
REST API 子类型
Rest API 有 3 种最常用的资源提供格式。 有时它们被称为子类型。
- REST API XML – 这种格式类似于 SOAP（简单对象访问协议）规范使用的早期方法。
- REST API JSON – 当使用基于 JavaScript 的文本格式进行数据交换时使用此格式。 这种格式是目前使用最广泛的。
- REST API GraphQL – 这种格式旨在满足对更大灵活性和效率的需求。 它是最新和最流行的规范方法。
有很多关于哪个更好用以及为什么更好的流行主题，以及许多使用比较。
结论
在本教程中，我们了解了 REST、API 和 RESTful API 概念。 我们已经探索了它是什么、它们的用途以及如何应用它们。 REST API 中使用的交互方式是一个比较宽泛的概念，并没有确切的规范。 最后，我们了解到 REST API 本身并不是标准，而是用于组件交互的架构风格。 为了进一步研究，我们建议对 REST API JSON 和 REST API GraphQL 方法进行更深入的检查，并将其应用到实践中。
我们的支持团队由才华横溢的 Linux 技术人员和系统管理员组成，他们对多种网络托管技术（尤其是本文中讨论的技术）有着深入的了解。
如果您是完全托管的 VPS 服务器， Cloud 专用，VMWare 私有 Cloud, 私人父服务器或专用服务器所有者，并且您对执行列出的任何步骤感到不舒服，可以通过电话@800.580.4985 与我们联系，一个 聊天 或支持票以协助您完成此过程。
[ad_2]