API的可观察性
API提供商需要观察他们的API，以获得关于他们是否以及如何在实践中被消费的有意义的数据。API观察性是一种监测形式，它被动地将API流量记录到观察性服务中。与传统的API监控不同，通过API可观察性，你可以。
监控交互，改善开发者体验 了解客户如何使用你的API 排除你的API故障
观察REST API是很好理解和支持的，但不是每个API都是REST API。特别是，GraphQL API在可观察性方面的表现非常不同。让我们深入了解这意味着什么，以及如何利用它的优势。
GraphQL API具有优势，但对可观察性构成挑战
许多组织通过监控用户访问的端点、记录错误信息和测量端点请求的延迟来处理API可观察性。这种策略对REST APIs来说很好，但对GraphQL APIs的API可观察性来说是不够的。
API消费者喜欢GraphQL，因为它足够灵活，可以在单个请求中查询多个来源的数据，并处理复杂的状态和缓存管理，使开发者有很好的体验。
GraphQL带来的好处不仅仅是针对API消费者。通过GraphQL，API提供者可以更新他们的API，而不影响现有的查询。用GraphQL提供数据也是平台无关的，因此API提供者可以选择最适合他们的数据提供者，包括将多个数据资源捆绑到一个查询中。支持GraphQL对于致力于建立一个伟大的开发者体验的API供应商来说是非常重要的，在这里查询是高效、强大和灵活的。
GraphQL的灵活性对于API提供商和API消费者来说都是一个重要的好处，但这种灵活性也意味着你需要对GraphQL API的可观察性采取不同的方法。让我们深入了解一下API观察能力在GraphQL上下文中带来的挑战，以及你如何处理这些挑战，以便你的组织能够观察你的GraphQL API。
在实践中观察GraphQL
为了从REST API中访问数据，开发人员会分别调用多个端点来拼凑客户需要的所有数据。对于复杂的应用程序，GraphQL方法更有吸引力，因为对不同数据源的请求都发生在一个单一的查询中。这意味着开发人员在使用GraphQL时只需要请求他们需要的数据，而REST查询结构不允许这种水平的可定制查询。例如，一个显示产品信息的购物应用程序，谁在销售它，以及交付需要多长时间，将由三个独立的REST API调用组成，像这样：f GET /category//productInfo GET /seller// GET /delivery//。
这需要多次GET调用来接收加载一个产品页面所需的所有数据。数据是从产品端点调用的，它返回的信息包括卖家的ID。有了seller-id，应用程序就会对seller端点进行数据调用，以获得关于卖家的信息，包括位置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做出长期决策。日志可以告诉你哪些GraphQL查询是成功的，谁是你最忠实的用户，哪些查询是首次使用的，以及哪些查询经常被捆绑在一起，等等。这可以为你的组织的客户成功战略提供信息，这将使你能够编写更有效的文档，找到那些在API调用中遇到挑战的用户，并为使用你的API的开发者提供更积极的支持。通过详细的日志，你可以对你的API有详细的了解。过滤查询是一种强大的技术，可以从你的GraphQL日志中汇总信息。
汇总对你的API的GraphQL查询，然后按字段名和参数值等类别进行过滤，将为你提供关于对你的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。
与REST API分析相比，GraphQL API分析可以使你在产品开发中获得优势，它们可以使你的组织更容易关注客户成功。如果你的组织了解首次使用你的API的用户在遇到挑战时是如何尝试查询的，你的客户支持就可以在解决客户遇到的问题时发挥更积极的作用，从而提供更详细和建设性的支持。如果一个客户因为调用了一个不再存在的REST端点而无法查询你的API，你的组织可能不会观察到这个故障，你的客户支持也无法联系到这个客户。这与GraphQL API调用形成对比，在GraphQL API调用中，查询到的是一个单一的端点。如果客户试图查询已经不存在的数据，你的监控将记录这一失败，你的客户支持可以直接联系到用户，帮助你的客户成功进行API调用。
这些年来，GraphQL已经变得非常流行，越来越多的团队选择使用GraphQL APIs。作为一个API供应商，观察你的GraphQL API可能是一个挑战。绝大多数API分析工具是为支持REST API而建立的，GraphQL往往是事后才想到的。Moesif则不同，它是为观察GraphQL和REST API而建立的，这样你的组织就可以促进客户的成功，为客户创造价值。Moesif提供了GraphQL观察能力的所有优势，并将其内置到产品中。当你实施GraphQL API时，你不需要放弃强大的分析工具!
