一起来看看Rest API与Web API有何区别

应用编程接口，或称API，是计算机程序或服务之间相互通信的一种方式。这种通信通常发生在一个上，由客户端消费的程序暴露出来。

本文将比较两种流行的构建API的 *** ：表征性状态转移（REst）API和Web API。

什么是REST API？

与流行的看法相反，REST API不是一个协议。它是一种架构，而且是开发API的更流行的架构。正如在《》一文提及，REST是无状态的，所以在请求之间没有数据或状态被存储。

REST还为构建通过HTTP通信的应用程序定义了多种架构约束：

• 客户端-服务器架构
• 无状态
• 统一的接口
• 缓存性
• 分层系统架构
• 按需编写代码

REST比其他API协议或架构更容易使用。它还提供了许多其他的好处，使它成为许多开发者构建API的首选：

• 多样的消息格式：大多与 *** ON一起用于序列化数据，但可以与多种消息格式一起工作，包括 *** ON、HTTP、纯文本和XML。这一系列的选择使它比服务对象访问协议（SOAP）等主要通过HTTP与XML一起工作的协议更有优势，与XML相比， *** ON等选项明显更轻，对数组的支持更灵活，而且更容易解析。
• HTTP *** ：REST通常使用GET、POST、PATCH、DELETE或PUT中的任何一种 *** 进行数据检索，并根据服务的实现提出请求。这些 *** 返回常见的HTTP成功和失败代码。其他 *** 包括OPTIONS、HEAD和TRACE。这些 *** 在服务之间是不一致的，因为一些提供者可能只根据他们的需要实现一个 *** 。
• 解耦架构：REST有一个客户-服务器架构，所以它的逻辑与表现形式是分离的–多个部分可以同时工作而不受干扰。
• 可扩展性： REST的API很简单，这使得它们可以直接使用。然而，如果你需要扩大规模，你可以创建新的端点来纳入更复杂的逻辑。
• 缓存性：虽然REST是无状态的，但客户端的服务器响应可以被缓存，以避免重复多余的请求。服务器响应通常会给出关于如何执行缓存的信息–客户端会在给定的时间内缓存请求。
• 安全性：在大多数情况下，REST端点是通过HTTPS端点暴露的，这确保了所有的API通信都是使用的安全。REST还支持其他授权和认证方案，如OAuth2和 *** ON Web Tokens（JWT）。

什么是Web API？

Web API只是一个通过HTTP访问服务器资源的接口。这个术语指的是概念，而不是任何特定的技术–Web API可以用各种技术建立，如和ASP.NET。Web API使用一个开源的接口，并利用许多客户端实体，如浏览器、智能手机、平板电脑和笔记本电脑。

*** 应用程序接口实现了协议规范的概念，如缓存、版本管理和不同的内容格式。一个Web API可能是也可能不是REST API，这取决于它的构建方式。Web API通常用于分布式系统，在不同的设备上提供服务，如智能手机和笔记本电脑，并且仅限于 *** 应用的客户端。

下面是两个广泛使用的Web API的例子：

• 谷歌APIs： 其中包括YouTube APIs，它允许开发者将YouTube视频嵌入他们的应用程序，如网站，以及，它允许开发者使用或Flash界面在网页上使用或嵌入谷歌地图。
• 推特API： 这些包括Twitter搜索API，它提供与Twitter搜索互动的 *** ，以及REST API，它允许你访问Twitter的核心数据。

Web API是作为系统对系统的互动进行的。以下是这样一个API内的数据可能的流动情况：

1. 客户端设备向 *** 服务器发送请求。
2. *** 服务器接收请求，对其进行处理，然后将其发回给客户端设备执行。
3. 输出结果被呈现给用户。

*** 应用程序接口的有利特征包括：

• 轻量级架构： Web API在带宽有限的设备中表现出色，如智能手机。
• 描述性的消息头： Web API有描述性的消息头，可能包含内容类型、安全方案或如何处理缓存的信息。
• 支持所有的数据类型： Web API的主体可以用于任何东西，包括二进制文件（视频、图像、文档）、普通XML、 *** ON和HTML。
• 面向资源的服务： 一个Web API可以以符合REST架构的方式暴露资源。
• 易于配置和设置： Web API很容易设置和运行。

Web API与REST API

现在，让我们更详细地比较这两种API。

架构的相似性

Web和REST API在架构上有一些相似之处，让我们来看看。

• 无状态性： HTTP请求是孤立发生的，从根本上说是无状态的，因为每个请求都包含足够的信息来完成它。多个请求只有通过共享信息，如或会话ID，才能相互关联。由于没有状态同步，减少了复杂性并提高了性能，因为服务器不需要跟踪客户端的请求。并发请求也可以在多个服务器上进行扩展。
• 分层架构： 它们都支持分层架构设计，API部署、请求认证和存储可以在多个服务器上发生。
• 面向资源： 在面向资源的架构中，资源被映射到统一资源识别码（URI）。Web和REST API都是面向资源的，因为它们通过URI暴露资源。
• 缓存性： 在REST和Web API中，每次调用时返回相同信息的查询都是缓存的。例如，一个端点上的OPTION调用将被缓存，因为无论调用多少次，其输出都是一样的。这个属性被称为idempotence，是确定数据何时可以被缓存的良好基础。Idempotence在REST中一直被考虑，尽管在Web API中并没有那么多。一个无效的API调用是指无论调用多少次，其结果都不会改变，即使服务器上有可能发生变化。idempotent *** 的例子包括GET、HEAD和OPTIONS。

架构差异

虽然Web APIs和REST APIs有类似的架构模式，但它们也有一些关键的区别。

• 客户端和服务器端的协调： REST APIs有松散的耦合架构，允许在客户端和服务器端独立开发。有了Web APIs，客户端和服务器之间的变化被更精细地协调。
• 接口： 根据实施细节，REST APIs倾向于使用行业标准的接口。Web API使用自定义接口，这取决于API供应商。

通信

Web API足够灵活，可以利用任何通信方式，而REST API主要用于 *** ON、XML和纯文本。这些选择意味着REST API在文本数据传输方面表现良好，例如针对数据库的创建、读取、更新和删除（CRUD）操作，但在涉及二进制数据时，限制性更强。

对于需要二进制数据的服务，如音乐或视频流服务，Web APIs提供了更好的体验，因为它们支持更多的消息格式。

使用案例

虽然这些API格式在很多情况下是可以互换的，但有几个场景是一个比一个好的：

• 云服务和应用程序： 由于其无状态的性质，REST API被用于云服务中，因为无状态的组件可以扩展和重新部署以适应变化。云服务和指标通常更好以REST API的形式暴露，因为几乎不需要定制代码。
• 流媒体服务： Web API对内存或带宽受限的设备上的应用二进制数据有更好的支持和低开销，所以它们最适合需要流媒体的服务。
• 数据库操作（CRUD）： 通过REST API暴露CRUD功能比Web API更简单和容易。

REST API对于需要访问不按简单层次排列的资源的复杂请求难以管理。这是因为它的URI引用了资源，这意味着管理这种情况需要操作URI路径、查询参数和请求主体，这违背了REST的目的。在这种情况下，Web API是首选，因为它允许定制，并对URI响应和请求头有广泛的支持。

由于支持异步调用等技术–使用REST架构不容易实现–Web API是满足复杂API需求的途径。

小结

Web和REST API是用来构建提供资源并通过HTTP进行通信的应用程序。REST描述了统一接口上的架构约束，而Web API一般是一个概念，可以是RESTful的，这取决于实现。

Web和REST API都是轻量级的格式，在很多情况下都可以互换。然而，与REST APIs相比，Web APIs提供了更多的定制体验，支持更多的消息类型，它支持服务器和客户端之间处理二进制数据的复杂互动。