GraphQL 与 RESTAPI 哪个更有利于 API 可观察性
API 可观察性
API 提供商需要观察他们的 API，以获取有关它们是否以及如何在实践中使用它们的有意义的数据。API 可观察性是一种监控形式，它被动地将 API 流量记录到可观察性服务中。与传统 API 监控不同，使用 API 可观察性，您可以：
监控交互以改善开发人员体验 了解客户如何使用您的 API 排除 API 故障
观察 REST API 已广为人知且受到支持，但并非每个 API 都是 REST API。特别是，GraphQL API 在可观察性方面表现得非常不同。让我们深入了解这意味着什么以及如何利用它。
GraphQL API 具有优势，但挑战可观察性
许多组织通过监控用户访问的端点、记录错误消息以及测量端点请求的延迟来实现 API 可观察性。此策略适用于 REST API，但对于使用 GraphQL API 的 API 可观察性而言还不够。
API 消费者喜欢 GraphQL，因为它足够灵活，可以在单个请求中查询来自多个来源的数据并处理复杂的状态和缓存管理，从而为开发人员带来出色的体验。
GraphQL 的好处不仅仅惠及 API 使用者。借助 GraphQL，API 提供商可以在不影响现有查询的情况下更新其 API。使用 GraphQL 提供数据也与平台无关，因此 API 提供商可以选择最适合他们的数据提供商，包括将多个数据资源捆绑到单个查询中。对于致力于打造出色的开发者体验的 API 提供商来说，支持 GraphQL 非常重要，因为查询高效、强大且灵活。
GraphQL 的灵活性对于 API 提供者和 API 使用者来说都是一项重要优势，但这种灵活性也意味着您需要采用不同的方法来实现 GraphQL API 的可观察性。让我们深入了解 API 可观察性在 GraphQL 环境中带来的挑战，以及您如何处理这些挑战，以便您的组织能够观察您的 GraphQL API。
在实践中观察 GraphQL
要从 REST API 访问数据，开发人员需要分别调用多个端点来拼凑客户端所需的所有数据。对于复杂的应用程序，GraphQL 方法更具吸引力，因为对不同数据源的请求都发生在单个查询中。这意味着开发人员在使用 GraphQL 时只需请求他们需要的数据，而 REST 查询结构不允许这种级别的可自定义查询。例如，一个显示产品信息（谁在销售该产品以及送货需要多长时间）的购物应用程序将包含三个单独的 REST API 调用，如下所示：f GET /category//productInfo 获取 /卖家// 获取 / 交付 //
需要多次 GET 调用才能接收加载产品页面所需的所有数据。数据从产品端点调用，返回包括卖家 ID 在内的信息。使用卖家 ID，应用程序向卖家端点发出数据调用以获取有关卖家的信息，包括位置 ID。最后，使用位置 ID 调用配送端点，以便页面知道此产品需要多长时间配送。每个响应都依赖于它之前的 API 调用中的信息，这种方法经常会获取过多或过少的数据。使用单个查询即可完成 GraphQL 调用，以仅从多个来源获取所需信息：
{
category{
name
product(product-id){
name
productInfo{
size
price
seller-id
}
seller(seller-id){
name
location-id
delivery(location-id){
name
}
}
}
}
} 虽然 GraphQL 方法的单个查询灵活性对开发人员来说很棒，但在使用 GraphQL 监控数据查询时，这带来了挑战。如果在使用 REST API 进行交易期间出现部分故障，或者端点无法返回数据，则 HTTP 请求将返回失败状态响应。当调用失败时，API 提供者和 API 使用者都会收到 HTTP 500 或 400 错误，而当端点调用成功时，则会收到成功的 HTTP 200。我们的购物示例中的 REST API 故障如下所示：
HTTP/1.1 400 Unprocessable Entity
{
"error":
{
"code": "400",
"message": "Product ID does not exist"
}
}使用 GraphQL，即使 API 调用未返回任何查询数据，部分故障也会成功解决并返回 HTTP 200。成功的 HTTP 响应是查询到达服务器的结果。如果查询调用不存在的数据或消费者无权访问的数据，则 HTTP 响应代码不会为您提供此信息。这会使处理错误更加困难，因为需要付出更多努力来诊断错误。API 消费者可以检查响应对象中的错误对象，该对象将显示哪个端点遇到错误以及导致错误的原因。以下是我们的 GraphQL 购物应用查询示例中的部分故障：
{
"errors": [
{ "path": [ "product" ],
"locations": [ { "line": 3, "column": 12 } ],
"extensions": {
"message": "Object not found",
"type": 2
}
}
]
}API 使用者能够通过在客户端检查 GraphQL 错误对象（如此处所示）来诊断错误。遗憾的是，如果您没有检查每个调用，则在服务器端可能无法捕获这些错误。API 提供商要解决此问题，他们需要监控 API 返回的 GraphQL 负载，以便他们可以像使用其 API 的开发人员一样检查错误对象。监控 API 负载还有一个额外的好处，就是让您了解开发人员如何使用您的 API、哪些查询最常见、哪些查询的延迟最低以及 API 使用者是否成功完成了查询。
通过观察学习
监控 GraphQL 负载的另一个好处是，您可以记录指标，以便根据开发人员访问 API 的方式做出有关 API 的长期决策。日志可以告诉您哪些 GraphQL 查询成功了、谁是您最忠实的用户、首次用户进行哪些查询以及哪些查询经常捆绑在一起等等。这可以为您组织的客户成功策略提供信息，从而使您能够编写更有效的文档、找到在 API 调用方面遇到挑战的用户，并为使用 API 的开发人员提供更主动的支持。通过详细的日志，您可以深入了解 API。过滤查询是一种从 GraphQL 日志中汇总信息的强大技术。
将 GraphQL 查询汇总到您的 API，然后按字段名称和参数值等类别进行过滤，这将为您提供有关对 GraphQL API 进行的大部分查询的可操作信息。这会告诉您 API 的哪些部分为客户创造了最大的价值，因此您知道在编写文档时应该关注什么、向开发人员介绍哪些查询以及哪些附加功能可能会为您的用户创造价值。如果您的组织同时拥有 GraphQL 和 REST API，则过滤查询将使您能够直接比较开发人员使用不同 API 的方式。
我们介绍了贵组织应如何实现 GraphQL API 可观测性，以及它对于专注于促进客户成功的组织的重要性。虽然 REST API 可观测性的实现更加直观，并且现有的 REST API 分析工具也更多，但 GraphQL 可观测性与 REST API 可观测性相比具有一些独特的优势。
GraphQL API 可观察性的优势
GraphQL 查询会准确指出需要哪些信息。REST API 消费者经常会获取不足或过度的数据，因为他们无法选择所需的特定数据。GraphQL 查询仅调用消费者需要的数据，这会告诉您哪些数据正在为消费者创造价值。使用 REST API 分析可能很难确定多个连续的 API 端点调用是来自消费者的单个事务的一部分，还是它们是不相关的事件。GraphQL 分析将单个事务所需的所有调用捆绑到一个查询中，因此您可以更清楚地了解消费者如何使用您的 API。
GraphQL API 分析可以让您在产品开发中比 REST API 分析更具优势，并且可以让您的组织更轻松地专注于客户成功。如果您的组织了解首次使用的用户在遇到挑战时如何尝试查询您的 API，那么您的客户支持就可以在解决客户遇到的问题方面发挥更积极的作用，从而提供更详细和更有建设性的支持。如果客户由于调用不再存在的 REST 端点而无法查询您的 API，您的组织可能不会观察到此故障，并且您的客户支持将无法联系到该客户。与 GraphQL API 调用相比，查询只会转到单个端点。如果客户尝试查询不再存在的数据，您的监控将记录此故障，并且您的客户支持可以直接联系用户，以帮助您的客户成功进行 API 调用。
多年来，GraphQL 已变得非常流行，越来越多的团队选择使用 GraphQL API。作为 API 提供商，观察您的 GraphQL API 可能具有挑战性。绝大多数 API 分析工具都是为支持 REST API 而构建的，而 GraphQL 通常是事后才考虑的。莫伊西夫与众不同，它旨在观察 GraphQL 和 REST API，以便您的组织能够促进客户成功并为客户创造价值。Moesif 提供了 GraphQL 可观察性的所有优势，并内置于产品中。实施 GraphQL API 时，您无需放弃强大的分析工具！
