包含内容
API 是一款产品，而非事后之举
好的 API 前后一致、文档完善、不容易被误用。一次集成是一个下午完成还是耗时一个月，差别就在这里。我们先设计契约，做好安全防护，再写好文档，让别人无需猜测就能在上面开发。
服务范围
- REST 与 gRPC API 的设计与实现
- 以 OpenAPI 文档为支撑的契约先行设计
- 做对的认证与授权（OAuth、令牌、作用域）
- 版本管理、限流与分页
- Webhook 与事件驱动集成
- 对您所倚赖的第三方 API 进行集成与编排
我们的工作方式
我们如何构建 API
契约先行，默认安全，边开发边写文档，让调用方（包括一年后的您自己）都能放心依赖。
- 1
契约先行
在编写实现之前，我们先设计 API 的接口，并就契约（资源、方法、错误）达成一致。
- 2
构建与保障安全
用 Go 或 Node.js 实现的地道实现，从一开始就内建认证、授权与输入校验。
- 3
编写文档
与代码并行生成准确的 OpenAPI 文档，让文档永不脱离实际。
- 4
测试与加固
契约测试与集成测试、限流，以及一轮安全检查。API 最常出问题的地方就是访问控制。
- 5
版本管理与运营
一套不会破坏既有消费方的版本管理策略，外加指标与日志，让您看清它的使用情况。
技术栈与方法
API 工具链
REST、gRPCOpenAPIGo、Node.jsOAuth、JWTPostgreSQL限流、webhook
版本化、文档齐全、经过契约测试。正是这种严谨，让别人可以放心依赖您的 API。
常见问题
API 开发常见问题
REST 还是 gRPC？
对于公开的、面向浏览器的 API，REST 是合适的默认选择：通用、可缓存、易于调用。gRPC 则适合服务之间的内部流量，您需要强类型、流式传输和更低开销的时候尤其合适。不少系统两者并用。我们会根据谁来调用这个 API、如何调用来决定，而不是追逐潮流。
API 会有完善的文档吗？
会的，而且文档是从契约生成的，不会悄悄与实现脱节。调用方拿到的是准确的 OpenAPI 文档，可以阅读、试用，也可以据此生成客户端。一个月的集成工作能缩短到一个下午，靠的就是这个。
你们如何保障 API 的安全？
认证与授权从一开始就设计进去：妥善处理令牌，按作用域限定权限，并在每个端点校验输入。访问控制失效是最常见的 API 漏洞，所以我们会专门测试授权，而不是假定框架会替您处理好。
你们能集成我们所倚赖的第三方 API 吗？
可以。我们集成并编排您的产品所依赖的外部 API，例如支付、身份和消息服务，配以合理的重试、错误处理和清晰的抽象层，日后更换某个供应商也不会波及整个代码库。