您当前的位置:首页 > 电脑百科 > 程序开发 > 编程百科

API 请求失败后发生了什么?

时间:2021-02-03 09:37:03  来源:  作者:

当一个 API 请求没能成功的时候,客户端最好能收到一个正确的 HTTP 错误状态,例如 409 或 500,这会是一个好的开始。不幸的是,尽管 400 Bad Request 可能就足够让我们知道错误出在哪里,但常见的情况是我们没有充足的信息来理解或解决实际遇到的问题。

许多 API 会在响应正文中为你提供更多细节,但令人遗憾的是,每个 API 都有自己的定制风格,不同的 API,甚至在各个端点使用的报告样式都不一样。这就需要定制的逻辑或者人工干预才能理解报告的内容。

但这种情况并非无可避免。先不用急着否定我。试着想象一个更好的世界,其中每个 API 都以相同的标准格式返回错误信息。

我们可以用一致的标识符来识别各种类型的错误,并能在任何地方轻松获得清晰的描述和元数据。你的通用 HTTP 客户端可以自动为任何错误提供详尽细节,你的客户端错误处理机制则能轻松可靠地过滤出你所关心的特定错误,并且你能使用单组共享逻辑来处理多种 API 的常见错误。

IETF 提出的 RFC 7807 标准希望定义一个 HTTP API 错误响应的标准格式,从而实现上述目标。它已经开始在现实世界中得到应用了。人们可以很容易地用它来支持现有的 API 和客户端,对于构建或使用 HTTP API 的人来说,这个标准值得关注。

标准错误格式为什么这么有用?

API 请求失败后发生了什么?

请不要这样做

谈这个问题前,让我们先退一步思考问题。HTTP 的一个关键特性是标准的响应状态代码,例如 200 或 404。正确使用这些代码可确保客户端自动理解响应的总体状态,并根据对应状态采取适当措施。

状态代码对错误处理来说特别有用。当请求收到意外的 500 状态时,几乎所有标准的 HTTP 客户端都会自动为你抛出一个错误,并不需要自定义规则来解析和解释各处的所有响应,从而确保意外错误能被可靠地报告,并可以在任何位置轻松处理。

这是很好的机制,但它也有很大的局限性。

实际上,一个 HTTP 400 响应可能表示以下任何一种情况:

  • 你的请求格式错误,无法解析
  • 你的请求意外为空,或缺少一些必需的参数
  • 你的请求有效,但仍然模棱两可,因此无法处理
  • 你的请求有效,但由于服务器错误,服务器认为请求无效
  • 你的请求有效,但请求的是完全不可能的内容
  • 你的请求已启动,但服务器拒绝了你提供的参数值
  • 你的请求已启动,但服务器拒绝了你提供的每个参数值
  • 你的请求已启动,但你的银行拒绝了其中包含的银行卡资料
  • 你的请求完成了一项购买操作,但请求的其他部分在稍后阶段被拒绝

这些全是错误,看起来都是由一个“坏”请求触发的 400 错误,但它们的内容却大相径庭。

状态代码可帮助我们区分错误和成功状态,但没法区分得太细致。因此,HTTP 客户端库不能在抛出的错误中包含任何有用的细节,每个 API 客户端都必须编写自定义的处理机制来解析每个失败的响应,并自行找出可能的原因和下一步应该做的操作。

如果失败的 HTTP 请求自动抛出的异常消息不仅仅是HTTP Error: 400 Bad Request,而是 Credit card number is not valid,这样岂不更好?

只要错误有一套标准格式,上面提到的每个错误就都可以有自己的唯一标识符,并包含标准化的说明内容和指向更多细节的链接。好处是:

  • 通用工具可以为你解析和解释错误的详细信息,而无需事先了解任何与 API 相关的信息。
  • API 能更安全地发起错误响应,因为它知道这些错误类型标识符意味着即使解释消息发生了更改,客户端也会一直按同一种理解方式识别错误。
  • 自定义 API 客户端可以检查错误类型以轻松处理特定情况,所有操作都以一种标准方式进行,适用于你所使用的每个 API,而无需从头开始编写 API 包装程序,也用不着每次都和 API 文档大战三百回合。

提案的错误格式长什么样?

为此,RFC7807 提出了一组用于返回错误的标准字段,以及两种将其格式化为 JSON 或 XML 的内容类型。

格式如下:

{
    "type": "https://example.com/probs/out-of-credit",
    "title": "You do not have enough credit.",
    "detail": "Your current balance is 30, but that costs 50.",
    "instance": "/account/12345/transactions/abc"
}

对于 XML 的等效格式:

<?xml version="1.0" encoding="UTF-8"?>
<problem xmlns="urn:ietf:rfc:7807">
    <type>https://example.com/probs/out-of-credit</type>
    <title>You do not have enough credit.</title>
    <detail>Your current balance is 30, but that costs 50.</detail>
    <instance>/account/12345/transactions/abc</instance>
</problem>

这些 RFC 为此定义了两种新的对应内容类型:Application/problem+json或application/problem+xml。返回错误的 HTTP 响应应在其Content-Type响应标头中包含适当的内容类型,并且客户端可以检查该标头以确认格式。

这个示例包括规范定义的一些标准化字段。完整列表是如下:

  • type:标识错误类型的 URI。在浏览器中加载这个 URI 应该转向这个错误的文档,但这不是严格要求的。此字段可用于识别错误类。理论上讲,将来站点甚至可以为常见情况共享标准化的错误 URI,以使通用客户端自动检测到它们。
  • title:错误的简短可读摘要。这是明确的指引,客户端必须使用 type 作为识别 API 错误类型的主要方式。
  • detail:较长的人类可读解释,带有完整的错误详细信息。
  • status:错误使用的 HTTP 状态代码。它必须与实际状态匹配,但可以包含在这里的 body 中以便参考。
  • instance:标识该特定故障实例的 URI。它可以作为发生的这个错误的 ID,和/或到特定故障更多详细信息的链接,例如显示失败的信用卡交易细节的页面。

所有这些字段都是可选的(不过type是强烈建议使用的)。内容类型允许自由包含其他数据,只要它们不与这些字段冲突即可,因此你也可以在此处添加自己的错误元数据,并包含所需的其他任何数据。实例 URI 和类型 URI 都可以是绝对 URI,也可以是相对 URI。

这里的思想是:

  • 通过返回带有合适Content-Type标头的错误响应,API 能很容易地表明它们正在遵循这一标准。
  • 这是一组简单的字段,可以轻松添加到大多数现有的错误响应顶部(如果还没有添加的话)。
  • 客户端只需在请求中包含Accept: application/problem+json(和/或+xml)标头,即可轻松表明支持状态,从而在必要时进行迁移。
  • 客户端逻辑可以轻松识别这些响应,并使用它们来显著改善通用和按 API 区分的 HTTP 错误处理操作。

怎样开始使用它呢?

目前,这是一个提案的标准,因此它尚未普及,并且在理论上可能会发生变化。

不过它已经用在很多地方,包括 5G 标准之类中,并且有了适用于大多数语言和框架的一些便捷工具,包括:

  • ASP.NET的内置支持
  • Node.js 的通用库和Express库
  • JAVA 的通用库和Spring Web MVC库
  • Python 的通用库和Django REST API库
  • Ruby 的通用、Rails和Sinatra库
  • php 的通用库和Symfony库
  • Rust、Go、Scala、Haskell的库...

也就是说,它已经渗透到了大多数主流生态系统中站稳了脚跟,并且即将更进一步:让更多 API 和客户端开始使用,直到实现大规模的普及状态,即大多数 API 的错误格式都遵循其标准,使它成为所有场景的默认值,让我们大家都能从中受益。

我们该如何做到这一点呢?

如果你在构建或维护一个 API:

  • 如果可以的话,请尝试使用适当的Content-Type响应标头以RFC 7807格式返回错误。
  • 如果你有了一种错误格式,并且需要维护该格式以保证兼容性,请检查是否可以在格式顶部添加这些字段,并对其进行扩展以符合标准。
  • 如果不能,请尝试检测传入的Accept标头中的支持,并在可能的情况下使用它来将原有的错误格式切换为标准格式。
  • 使用你的 API​框架(比如这个框架)记录错误,表明它们将来会转向标准错误格式。

如果你在使用一个 API:

  • 检查这些内容类型的错误响应,并用那里提供的数据改进你的错误报告和处理工作。
  • 考虑在请求中包含带有这些内容类型的Accept标头,以表明支持状态并在可用时启用标准错误。
  • 向你使用的 API 提出抱怨,希望它们以这种标准格式返回错误,就像抱怨那些不会费心返回正确状态代码的 API 一样。

至于大家:

  • 参与其中!这是 IETF 新的“HTTP API 的构建块”工作组旗下的规范。你可以加入邮件列表以阅读并参与有关该规范和其他可行 API 标准规范规范的讨论,包括速率限制和API弃用等。
  • 向你的同事和开发者朋友做宣传,并帮助大家简化错误处理的工作。

原文链接:

https://httptoolkit.tech/blog/http-api-problem-details/



Tags:API   点击:()  评论:()
声明:本站部分内容及图片来自互联网,转载是出于传递更多信息之目的,内容观点仅代表作者本人,如有任何标注错误或版权侵犯请与我们联系(Email:2595517585@qq.com),我们将及时更正、删除,谢谢。
▌相关推荐
近日只是为了想尽办法为 Flask 实现 Swagger UI 文档功能,基本上要让 Flask 配合 Flasgger, 所以写了篇 Flask 应用集成 Swagger UI 。然而不断的 Google 过程中偶然间发现了...【详细内容】
2021-12-23  Tags: API  点击:(6)  评论:(0)  加入收藏
一个项目的大部分API,测试用例在参数和参数值等信息会有很多相似的地方。我们可以复制API,复制用例来快速生成,然后做细微调整既可以满足我们的测试需求1.复制API:在菜单发布单...【详细内容】
2021-12-14  Tags: API  点击:(20)  评论:(0)  加入收藏
10月18号, W3C中网络平台孵化器小组(Web Platform Incubator Community Group)公布了HTML Sanitizer API的规范草案。这份草案用来解决浏览器如何解决XSS攻击问题。 网络安全中...【详细内容】
2021-12-07  Tags: API  点击:(18)  评论:(0)  加入收藏
当我们通过kubectl来查看、修改Kubernetes资源时,有没有想过后面的接口到底是怎样的?有没有办法探查这些交互数据呢?Kuberenetes客户端和服务端交互的接口,是基于http协议的。所...【详细内容】
2021-11-23  Tags: API  点击:(29)  评论:(0)  加入收藏
前言客户端请求API,通常需要通过返回码来判断API返回的结果是否符合预期,以及该如何处理返回的内容等。相信很多同学都吃过返回码定义混乱的亏,有的API用返回码是int类型,有的是...【详细内容】
2021-10-28  Tags: API  点击:(51)  评论:(0)  加入收藏
凭借着平缓的学习曲线和简单直接的语法,Python在全球范围内的受欢迎程度,正在呈指数级增长。该编码语言往往可以被用于Web开发、软件开发、数学计算、系统脚本、以及几乎所有...【详细内容】
2021-09-22  Tags: API  点击:(47)  评论:(0)  加入收藏
Guava提供的RateLimiter可以限制物理或逻辑资源的被访问速率,咋一听有点像java并发包下的Samephore,但是又不相同,RateLimiter控制的是速率,Samephore控制的是并发量。RateLimit...【详细内容】
2021-09-17  Tags: API  点击:(72)  评论:(0)  加入收藏
前言前后端分离开发模式中,api文档是最好的沟通方式。今天就来说一说如何整合Swagger生成一套漂亮、美观、实用的接口文档。 源码传送门: https://gitee.com/huoqstudy/xiliu-...【详细内容】
2021-09-08  Tags: API  点击:(65)  评论:(0)  加入收藏
注:商业级功能效果演示,非开源,无源码。研发基础在之前AJAX请求数据加密效果之上,更进一步,对返回数据加密。之前是单纯用于登录场景。更广泛的场景是所有此类AJAX WEB API接口。...【详细内容】
2021-09-03  Tags: API  点击:(73)  评论:(0)  加入收藏
最近一连串的 API 安全事件(Peloton、Experian、Clubhouse 等)无疑迫使许多安全和开发团队仔细检查他们的 API 安全状况,以确保它们不会成为下一个被攻击对象。创建面向外部受...【详细内容】
2021-09-01  Tags: API  点击:(59)  评论:(0)  加入收藏
▌简易百科推荐
摘 要 (OF作品展示)OF之前介绍了用python实现数据可视化、数据分析及一些小项目,但基本都是后端的知识。想要做一个好看的可视化大屏,我们还要学一些前端的知识(vue),网上有很多比...【详细内容】
2021-12-27  项目与数据管理    Tags:Vue   点击:(1)  评论:(0)  加入收藏
程序是如何被执行的&emsp;&emsp;程序是如何被执行的?许多开发者可能也没法回答这个问题,大多数人更注重的是如何编写程序,却不会太注意编写好的程序是如何被运行,这并不是一个好...【详细内容】
2021-12-23  IT学习日记    Tags:程序   点击:(9)  评论:(0)  加入收藏
阅读收获✔️1. 了解单点登录实现原理✔️2. 掌握快速使用xxl-sso接入单点登录功能一、早期的多系统登录解决方案 单系统登录解决方案的核心是cookie,cookie携带会话id在浏览器...【详细内容】
2021-12-23  程序yuan    Tags:单点登录(   点击:(8)  评论:(0)  加入收藏
下载Eclipse RCP IDE如果你电脑上还没有安装Eclipse,那么请到这里下载对应版本的软件进行安装。具体的安装步骤就不在这赘述了。创建第一个标准Eclipse RCP应用(总共分为六步)1...【详细内容】
2021-12-22  阿福ChrisYuan    Tags:RCP应用   点击:(7)  评论:(0)  加入收藏
今天想简单聊一聊 Token 的 Value Capture,就是币的价值问题。首先说明啊,这个话题包含的内容非常之光,Token 的经济学设计也可以包含诸多问题,所以几乎不可能把这个问题说的清...【详细内容】
2021-12-21  唐少华TSH    Tags:Token   点击:(9)  评论:(0)  加入收藏
实现效果:假如有10条数据,分组展示,默认在当前页面展示4个,点击换一批,从第5个开始继续展示,到最后一组,再重新返回到第一组 data() { return { qList: [], //处理后...【详细内容】
2021-12-17  Mason程    Tags:VUE   点击:(14)  评论:(0)  加入收藏
什么是性能调优?(what) 为什么需要性能调优?(why) 什么时候需要性能调优?(when) 什么地方需要性能调优?(where) 什么时候来进行性能调优?(who) 怎么样进行性能调优?(How) 硬件配...【详细内容】
2021-12-16  软件测试小p    Tags:性能调优   点击:(19)  评论:(0)  加入收藏
Tasker 是一款适用于 Android 设备的高级自动化应用,它可以通过脚本让重复性的操作自动运行,提高效率。 不知道从哪里听说的抖音 app 会导致 OLED 屏幕烧屏。于是就现学现卖,自...【详细内容】
2021-12-15  ITBang    Tags:抖音防烧屏   点击:(23)  评论:(0)  加入收藏
11 月 23 日,Rust Moderation Team(审核团队)在 GitHub 上发布了辞职公告,即刻生效。根据公告,审核团队集体辞职是为了抗议 Rust 核心团队(Core team)在执行社区行为准则和标准上...【详细内容】
2021-12-15  InfoQ    Tags:Rust   点击:(24)  评论:(0)  加入收藏
一个项目的大部分API,测试用例在参数和参数值等信息会有很多相似的地方。我们可以复制API,复制用例来快速生成,然后做细微调整既可以满足我们的测试需求1.复制API:在菜单发布单...【详细内容】
2021-12-14  AutoMeter    Tags:AutoMeter   点击:(20)  评论:(0)  加入收藏
最新更新
栏目热门
栏目头条