API怎么选？比较SOAP，REST，GraphQL和RPC( 三 ) _API

当服务实现REST的某些功能和RPC的某些功能时，在REST和RPC之间确实可能存在一个灰色区域。REST基于资源或名词，而不是基于动作或动词。

文章插图
> Opposing operations in verb-centric RPC to the ones in noun-centric REST
在REST中，使用GET，POST，PUT，DELETE，OPTIONS和PATCH等HTTP方法完成操作。

文章插图
> Source: Thomas Davis
REST的优点客户端和服务器解耦。REST尽可能使客户端和服务器脱钩，与RPC相比，REST可以提供更好的抽象性。具有抽象级别的系统能够封装其详细信息，以更好地标识和维持其属性。这使得REST API足够灵活，可以随着时间的推移而发展，同时保持稳定的系统。
可发现性。客户端与服务器之间的通信描述了所有内容，因此不需要外部文档即可了解如何与REST API进行交互。
缓存友好。REST重用了许多HTTP工具，是唯一一种可以在HTTP级别上缓存数据的样式。相反，在任何其他API上进行缓存实现将需要配置其他缓存模块。
多种格式支持。支持多种格式用于存储和交换数据的能力是REST当前成为构建公共API的主要选择的原因之一。
REST缺点：没有单一的REST结构。没有建立REST API的正确方法。如何对资源进行建模以及要对哪些资源进行建模将取决于每种情况。这使得REST在理论上很简单，但在实践中却很困难。
大负载。REST返回很多丰富的元数据，以便客户端可以仅从响应中了解有关应用程序状态的所有必要信息。对于具有大量带宽容量的大型网络管道而言，这种聊天状态并不重要。但这并非总是如此。这是Facebook在2012年提出GraphQL样式的关键驱动因素。
过度获取和不足获取问题。REST响应包含的数据过多或不足，通常会导致需要另一个请求。
REST用例管理API 。专注于管理系统中对象并面向许多使用者的API是最常见的API类型。REST帮助此类API具有强大的可发现性，良好的文档编制，并且非常适合此对象模型。
简单的资源驱动型应用程序。REST是一种非常有用的方法，用于连接不需要查询灵活性的资源驱动型应用。
GraphQL：仅查询所需的数据它需要多次调用REST API才能返回所需的人员。因此，GraphQL被发明为改变游戏规则的人。
GraphQL是一种语法，描述了如何进行精确的数据请求。对于具有许多相互引用的复杂实体的应用程序数据模型而言，实现GraphQL是值得的。

文章插图
> How to retrieve only the needed data from the GraphQL endpoint, Source: Mohit Tikoo
如今，GraphQL生态系统正在通过库和强大的工具（如Apollo，GraphiQL和GraphQL Explorer）进行扩展。
GraphQL如何工作GraphQL从构建模式开始，该模式是对您可以在GraphQL API中进行的所有查询及其返回的所有类型的描述。模式构建非常困难，因为它需要使用模式定义语言（SDL）进行强类型化。
在查询之前具有架构，客户端可以验证其查询，以确保服务器能够对其进行响应。在到达后端应用程序时，将针对整个模式解释GraphQL操作，并使用前端应用程序的数据进行解析。该API向服务器发送一个庞大的查询后，会返回一个JSON响应，其中包含我们所需数据的确切形状。

文章插图
> Query execution in GraphQL, Source: Jonas Helfer
除了RESTful CRUD操作之外，GraphQL的订阅还允许来自服务器的实时通知。
GraphQL的优点键入的架构。GraphQL会提前发布其功能，从而提高其可发现性。通过将客户端指向GraphQL API，我们可以找出可用的查询。
非常适合类似图形的数据。数据关系很深，但不适合平面数据。
没有版本控制。版本控制的最佳做法是根本不对API进行版本控制。
REST提供了多个API版本，而GraphQL使用的是一个不断发展的版本，它可以持续访问新功能，并有助于提供更清洁，更可维护的服务器代码。
详细的错误消息。GraphQL以类似于SOAP的方式提供发生错误的详细信息。它的错误消息包括所有解析器，并引用发生故障时的确切查询部分。
灵活的权限。GraphQL允许选择性地公开某些功能，同时保留私人信息。同时，REST体系结构不会部分显示数据。全部或全无。
GraphQL的缺点性能问题。GraphQL权衡了复杂性。一个请求中的嵌套字段太多会导致系统过载。因此，对于复杂的查询，REST仍然是更好的选择。