种主流的API架构风格对比.docxVIP

4种主流的API架构风格对比 2021-01-16 两个单独的应用程序需要中介程序才能相互通信。因而，开发人员经常需要搭建桥梁——也就是应用程序编程接口（API），来允许一个系统访问另一个系统的信息或功能。 为了快速、大规模地集成不同的应用程序，API 使用协议或规范来定义那些通过网络传输的消息的语义和信息。这些规范构成了 API 的体系结构。 在过去，人们已经发布了多种不同的 API 架构风格。每个架构风格都有它独有的标准化数据交换的模式。这一系列的 API 架构风格的选项，引发了大量的关于哪种架构风格才是最好的争辩。 （不同时间的 API 架构风格，图源：Rob Crowley） 今日，很多 API 的使用者将 REST 称作“消亡的 REST”（REST in peace），并且为 GraphQL 感到欢欣鼓舞。而十年前，又完全是另一幅光景：REST 是替代 SOAP 的赢家。这些观点的问题在于，它们的动身点只是为某种技术背书，而不是去考虑它实际的属性和特性如何与当前的需求相婚配。 （四种 API 架构风格） RPC：调用另一个系统的函数 近程过程调用是一种允许在不同上下文中近程执行函数的规范。RPC 扩展了本地过程调用的概念，并将其放在 HTTP API 的上下文中。 最后的 XML-RPC 是存在问题的，由于很难确保 XML 有效负载的数据类型。因而，后来 RPC API 开头使用一个更具体的 JSON-RPC 规范，该规范被认为是 SOAP 的更简约的替代方案。gRPC 是 Google 在 2021 年开发的最新 RPC 版本。gRPC 可插拔支持负载均衡、追踪、运转情况检查和身份验证，它格外适合连接不同的微服务。 1 RPC 的工作机制 客户端调用一个近程的过程，将参数和附加信息序列化为消息，然后将消息发送到服务端。服务端在接遭到消息后，将信息的内容反序列化，执行所恳求的操作，然后将结果发送回客户端。客户端和服务端各自担任参数的序列化和反序列化。 （近程过程调用的机制，图源：Guru99） 2 RPC 的优势 简约直接的交互。RPC 使用 GET 来猎取信息，使用 POST 来处理其他全部操作。服务端和客户端之间交互的机制归结为调用端点并获得响应。 易于添加新函数。假如 API 有了新的需求，我们可以轻松地添加另一个执行这个需求的端点：1）编写一个新函数，并将其放在一个新端点之后；2）现在，客户可以访问这个端点，并猎取符合其需求的信息。 高功能。轻量级的有效负载不会对网络产生压力，以此供应高功能，这对于共享服务器和在工作站网络上执行并行计算格外重要。RPC 还能够优化网络层，使得不同服务之间每天发送海量消息变得格外高效。 3 RPC 的不足 和底层系统紧密耦合。API 的笼统级别有助于其可重用性。API 与基础系统的耦合越紧密，对其他系统的可重用性就越差。RPC 与基础系统的紧密耦合不允许其在系统函数和外部 API 之间建立笼统层。这很简约引起平安问题，由于关于基础系统的细节实现很简约会泄漏到 API 中。 RPC 的紧密耦合使得可伸缩性要求和松散耦合的团队难以实现。因而，客户端要么会担忧调用特定端点的带来的任何可能的副作用，要么需要尝试弄清楚要调用的端点，由于客户端不了解服务器如何命名其函数。 可发觉性低。在 RPC 中，无法对 API 进行检验总结，或者发送恳求来开头理解依据需求应当调用哪个函数。 函数爆炸性增长。创建新函数格外简约。因而，相较于重新编辑现有的函数，我们会倾向于创建新的功能，最终产生大量难以理解的、功能堆叠的函数。 4 RPC 的用例 RPC 模式在八十年月开头使用，但这并不意味着它已经过时了。诸如 Google、Facebook（Apache Thrift）和 Twitch（Twirp）这样的大公司如今正在内部使用高功能的 RPC 版本，来执行极高功能、低开销的消息传递。它们浩大的微服务系统要求内部通信在使用短消息的情况下也保持清楚。 命令 API。RPC 是用于将命令发送到近程系统的正确选择。例如，Slack API 是格外以命令为中心的：加入频道、离开频道、发送消息。因而，Slack API 的设计者以类似于 RPC 的样式对其进行了建模，使其小巧、紧凑并且易于使用。 用于内部微服务的客户特定的 API。由于是在单个供应者和单个使用者之间建立直接的集成，我们不想像 REST API 那样，花太多时间通过网络传输大量的元数据。凭仗高消息速率和消息功能，gRPC 和 Twirp 成为了用于微服务的牢靠用例。通过在底层使用 HTTP 2，gRPC 能优化网络层，使其格外高效地在不同服务之间每天传送大量信息。然而，假如你并不是要着眼于提高网络功能，而是要在发布高度独立的微服务团队