AI实践哪家强?来 AICon, 解锁技术前沿,探寻产业新机! 了解详情
写点什么

Heroku 的 HTTP API 设计指南

  • 2014-09-03
  • 本文字数:1653 字

    阅读完需:约 5 分钟

Wesley Beary 是 Heroku API 团队的成员,他整理了一份用于创建 HTTP+JSON API 的指南,并以非常精炼的语言对该指南进行了陈述。

该指南以若干条建议开始:

  • 需要所有的 API 调用都使用 TLS。针对非 TLS 的调用以 403 Forbidden 进行回应
  • 始终对 API 进行版本化。使用 Accept 头部来指定版本。需要客户端指定 API 版本,而不是简单地以默认版本进行回应。
  • 使用 ETag 头部来支持资源的缓存
  • 识别出每个具有 X-Request-ID 的响应;这对达成日志跟踪或调试等目的会非常有用
  • 使用 Range, Content-Range, Next-Range 来处理数据量较大的响应

针对发出的请求,该指南提到了如下几点:

  • 返回合适的状态码,例如 200: 成功的 GET 或 同步的 DELETE, PATCH

    201: 成功且同步的 POST

    401: 未经授权的调用

    429: 请求频率超过限制

    等等。

  • 当可用时总是返回完整的资源

  • 接受请求中那些与 JSON 响应对称的序列化 JSON

  • 使用一致的路径格式。除非特指单例,否则资源名称应该使用复数的形式

  • 路径和属性都使用小写字母,从而与主机名保持对齐

  • 允许为某些资源指定除 UUID 以外的名称,例如像应用的名称

  • 尝试通过尽可能将资源配置到离根路径较近的路径位置来限制资源嵌套的深度

当谈到关于响应的部分,Beary 建议如下:

  • 为每个资源使用全局唯一的 ID
  • 为资源提供标准的时间戳
  • 针对时间戳,应该使用格式为 ISO8601 的 UTC 时间
  • 将外键关系嵌入到当前资源从而可以包含更多关联资源的详情,并且无须修改响应的结构,
  • 提供详细的错误信息,包括一个机器可读的 ID、一段人类可读的错误消息以及一个可选的指向更多细节的 URL
  • 设定一个请求频率限制,然后可以使用一个像 RateLimit-Remaining 这样的头部来在每个响应中告知客户端可用请求令牌的剩余请求数量
  • 应该对所有响应中的 JSON 进行压缩

该指南还包括了更多的相关忠告:

  • 以机器可读的格式提供 JSON schema
  • 包括为开发者而准备的详细的 API 文档
  • 允许开发者测试 API
  • API 应该根据它们的稳定性状态分别标记为:原型(prototype)/ 开发(development)/ 生产(production)

我们就如何总结出这些指南以及如何对它们中的部分进行解释向 Beary 进行了采访。

InfoQ:你从一开始就拥有一份 API 设计指南吗?

WB: 我从早期就拥有了一部分指南,但是它们都相当地粗糙,且仅仅存在于我的脑海之中。自从我开始 github.com/fog/fog 上及其相关的工作以来,我已经消费过很多不同的 API,这帮助我近一步形成了这些观点。

InfoQ:如果你一开始没有这些指南,那么你是如何开发 API 的?通过不断的迭代吗?

WB: 因为缺乏一个更加正式的指南,这无疑会是一个迭代的过程。不幸的是,除了有点慢之外,迭代的过程也是无法伸缩的,它成为了我向 API 新增内容的障碍。所以我们构建了该指南来推动这些决策制定的分发工作。我们会继续进行迭代,但是就指南本身而言通常现在也处于迭代之中。我们可以看到有很多正在进行中的讨论( github.com/interagent/http-api-design/issues ),伴随着我们学习到更多的经验以及其他开发者对这些指南的采用,这些讨论将持续对我们的这个文档进行阐明和发展。

InfoQ:为什么建议在针对 PUT 或 DELETE 操作时返回整个资源?

WB:异常情况是接口和指南中的对立部分。有时客户端期望得到整个资源,而出于对优化的考虑我们通常会对客户端的这种期望不加理会。我认为可以将该行为视为是可选的,通常可选的行为在很多场景中都是有意义的,但是具备一个简单、有用的默认选项是有价值的。也就是说,这是一个有争议的观点,而在 https://github.com/interagent/http-api-design/issues/9 上可以找到一些正在进行中的讨论,它们对这个观点的优缺点进行了更加深入地探讨。

InfoQ:为什么只使用 ISO8601 格式的 UTC 时间?

WB: 这与返回整个资源相似,具有一致的规则(不考虑异常)可以更容易地对你正在做的事情进行思考,从而减少你在设计某些事物的时候需要做出决策的次数。同样的,时区是疯狂而可怕的。我已经记不清我所遇到或引起的与时区相关的错误次数了。为了有望减少问题,我们选择了一个我们所熟知的时区和格式来在各方面进行使用。

查看英文原文: Heroku’s HTTP API Design Guide

2014-09-03 01:2011475
用户头像

发布了 52 篇内容, 共 24.0 次阅读, 收获喜欢 5 次。

关注

评论

发布
暂无评论
发现更多内容

如何定期清理数据库中的无效数据?

NineData

数据清理 数据归档 NineData 无效数据 优化数据库

一键开启 GPU 闲置模式,基于函数计算低成本部署 Google Gemma 模型服务

阿里巴巴云原生

阿里云 云原生 函数计算

等保测评与信息安全管理体系认证的区别

行云管家

等保 等级保护 等保测评

Tapjoy from Unity 推出“每日奖励”积分墙广告,以增强用户粘性并提升投放 ROAS

极客天地

面试八股文,自有其道理

老张

面试 专业能力

超越基础设施:深度探讨平台工程的关键支柱

SEAL安全

架构 基础设施 平台工程

带你走进 HarmonyOS:前端如何迎接新技术的到来

京东科技开发者

基于 K8s 容器集群的容灾架构与方案

阿里巴巴云原生

阿里云 Kubernetes 云原生

开放原子开源大赛—基于OpenHarmony的团结引擎应用开发赛正式启动!

OpenHarmony开发者

提升地理空间分析效率,火山引擎ByteHouse上线GIS能力

字节跳动数据平台

数据库 大数据

npm是如何处理多版本依赖的?

伤感汤姆布利柏

代码精简执行过程

京东科技开发者

【体验有奖】用 AI 画春天,函数计算搭建 Stable Diffusion WebUI

阿里巴巴云原生

阿里云 云原生 AIGC

2024-03-13:用go语言,给定一个二叉搜索树, 找到该树中两个指定节点的最近公共祖先。 输入: root = [6,2,8,0,4,7,9,null,null,3,5], p = 2, q =

福大大架构师每日一题

福大大架构师每日一题

编译GreatSQL with RocksDB引擎

GreatSQL

万字带你了解ChatGLM

华为云开发者联盟

人工智能 华为云 大模型 华为云开发者联盟

得物布局构建耗时优化方案实践

得物技术

xml 前端

代币开发:2024年代币开发主要因素

区块链软件开发推广运营

dapp开发 区块链开发 链游开发 NFT开发 公链开发

十分钟掌握分布式数据库开发:OpenMLDB 开发者镜像详解

第四范式开发者社区

人工智能 机器学习 数据库 开源 特征

【一文读懂】基于Havenask向量检索+大模型,构建可靠的智能问答服务

阿里技术

向量检索 LLM 智能问答 Havenask 召回搜索引擎

数据“隐领”未来!【隐私计算实训营】限时免费招募!

隐语SecretFlow

数据分析 数据安全 隐私计算

ppt美化ai软件有哪些?这5款AI工具一键生成PPT!

彭宏豪95

人工智能 PPT AIGC 效率软件 AI生成PPT

网络安全等级测评师考试培训可以参考哪些资料?

行云管家

等保 等级保护 等保测评师

「飞桨星河社区创作者激励计划」全新上线!丰富权益,等你领取~

飞桨PaddlePaddle

百度 开发者社区 百度飞桨 星河社区 飞桨星河社区

为了跳槽或提升自己,你会先学习哪一门编程语言?

小魏写代码

软件测试学习笔记丨服务端问题定位常用linux指令集合

测试人

Linux 软件测试

一个数据库死锁竟然被测试发现了,这你敢信

京东科技开发者

[自研开源] MyData v0.7.2 更新日志

LIEN

开源 数据集成 业务融合 API对接 mydata

ByteSRC奖励再升级,单个重大漏洞提升至10万元

极客天地

即时通讯技术文集(第35期):IM群聊技术合集(Part2) [共12篇]

JackJiang

即时通讯;IM;网络编程

Heroku的HTTP API设计指南_语言 & 开发_Abel Avram_InfoQ精选文章