产品背景知识——API、SDK、Library、Framework、Protocol

产品背景知识——API、SDK、Library、Framework、Protocol

API和SDK

API（Application Programming Interface，应用程序编程接口）和SDK（Software Development Kit，软件开发工具包）是软件开发中的两个核心概念，它们既有区别又有紧密联系。以下是详细解释：

1. API 与 SDK 的区别

类比：

• API 像是餐厅的菜单，告诉你有哪些菜（功能）可以点，如何点（调用规则）。
• SDK 像是厨房工具包，不仅包含菜单，还提供厨具（库）、菜谱（示例代码）、厨师手册（文档），让你能更高效地做菜。

2. API 与 SDK 的关系

• 依赖关系：SDK 通常封装了底层 API，提供更友好的编程接口。例如，AWS SDK 封装了 AWS 的 REST API，开发者无需直接处理 HTTP 请求。
• 互补性：API 是 SDK 的核心组成部分，但 SDK 还包含其他辅助开发的工具。
• 层级关系：API 是底层交互协议，SDK 是上层开发工具。

3. 什么是“根据 API 手搓 SDK”？

当某个服务（如微信支付、OpenAI）只提供了原始的 API（如 RESTful HTTP 接口），但没有官方 SDK 时，开发者可以手动封装这些 API，实现一个自定义的 SDK。这个过程包括：

1. 分析 API 文档：理解接口的请求方式（GET/POST）、参数、认证（如API Key）、返回格式（JSON/XML）。
2. 封装底层调用：
   • 用代码封装 HTTP 请求（如使用 Python 的 requests 库）。
   • 处理认证（如自动添加请求头 Authorization: Bearer xxx）。
   • 统一处理错误（如将 HTTP 状态码转为异常抛出）。
3. 提供友好接口：
   • 将原始 API 转换为面向对象的类和方法（如 client.get_user(id) 而非直接发 HTTP 请求）。
   • 添加类型提示、文档字符串（方便其他开发者使用）。
4. 加入工具函数：
   • 简化常见操作（如分页查询自动合并多页结果）。
   • 提供本地缓存、重试机制等。

4. 示例：手搓一个简易 SDK

假设有一个天气预报 API：

• 原始 API：GET https://api.weather.com/v1/forecast?city=北京&key=YOUR_KEY

手搓 SDK 的伪代码（Python）：

import requests

class WeatherSDK:
    def __init__(self, api_key):
        self.api_key = api_key
        self.base_url = "https://api.weather.com/v1/forecast"

    def get_forecast(self, city):
        """获取天气预报（封装原始API）"""
        params = {"city": city, "key": self.api_key}
        response = requests.get(self.base_url, params=params)
        response.raise_for_status()  # 自动处理错误
        return response.json()

# 使用SDK（无需关心底层HTTP细节）
sdk = WeatherSDK(api_key="123")
forecast = sdk.get_forecast("北京")

5. 为什么需要手搓 SDK？

• 减少重复代码：避免在每个项目中重复写 HTTP 请求逻辑。
• 统一维护：API 变动时只需修改 SDK 内部，不影响业务代码。
• 提升体验：提供更符合语言习惯的接口（如链式调用、异步支持）。

总结

• API 是规则，SDK 是工具包。
• 手搓 SDK 的本质是通过封装原始 API，隐藏复杂性，提供更高层的抽象。
• 现代开发中，许多 SDK 是官方提供的（如 AWS SDK、TensorFlow SDK），但遇到只有 API 的情况时，自己造轮子也很常见。

相关概念扩展

1. 相关概念扩展

（1）Library（库）

• 定义：一组可复用的代码模块（如函数、类），用于解决特定问题（如加密、图像处理）。
• 与SDK的关系：
  • SDK 通常包含多个库（如 Android SDK 包含 android.util、android.os 等库）。
  • 但库不一定是 SDK，例如 Python 的 requests 是一个独立的 HTTP 请求库。

示例：

• NumPy（数学计算库）是独立的库，不是 SDK。
• Firebase SDK 包含多个库（如认证库 firebase-auth、数据库库 firebase-database）。

（2）Framework（框架）

• 定义：一套约定俗成的架构，提供基础结构和流程控制（如 MVC 模式），开发者在其规则下填充业务代码。
• 与SDK/API的关系：
  • 框架通常内置 SDK 和 API（如 Django 框架提供了 ORM API 和开发工具）。
  • 反向控制：框架调用你的代码（通过回调或继承），而 SDK/库是你调用它。

示例：

• 前端框架：React、Vue（提供组件化开发的规则和工具）。
• 后端框架：Spring（Java）、Ruby on Rails（内置数据库访问 API 和脚手架工具）。

（3）Protocol（协议）

• 定义：数据交换的规则标准，API 的实现依赖于协议。
• 常见协议：
  • HTTP/HTTPS：RESTful API 的基础。
  • WebSocket：实时双向通信（如聊天应用）。
  • gRPC：基于 HTTP/2 的高性能 RPC 协议。
• 与API的关系：API 是协议的上层抽象。例如，RESTful API 使用 HTTP 协议，但隐藏了底层的 TCP 握手细节。

（4）CLI（命令行接口）

• 定义：通过命令行调用的工具，通常用于自动化或管理服务。
• 与SDK的关系：
  • 某些 SDK 提供 CLI 工具（如 AWS CLI 是 AWS SDK 的命令行版本）。
  • CLI 可能直接调用底层 API（如 kubectl 调用 Kubernetes API）。

示例：

• git（版本控制的 CLI）、docker（容器管理的 CLI）。

（5）IDE（集成开发环境）

• 定义：集成了代码编辑、调试、编译等功能的开发工具（如 VS Code、IntelliJ）。
• 与SDK的关系：
  • IDE 可能内置或关联特定 SDK（如 Android Studio 内置 Android SDK）。
  • 提供 SDK 的智能提示、调试支持。

2. 技术栈中的层级关系

从底层到上层，典型的技术栈分层如下：

协议（HTTP/gRPC） → API（REST/GraphQL） → 库（requests/axios） → SDK（AWS SDK） → 框架（React/Spring） → 应用（你的代码）

• 越底层：越接近网络/硬件，灵活性高但使用复杂（如直接写 Socket 通信）。
• 越上层：封装度越高，开发效率高但灵活性降低（如直接用 SDK 上传文件到云存储）。

3. 实际场景示例

场景：开发一个微信小程序支付功能

1. 协议层：微信支付使用 HTTPS 协议保证安全。
2. API层：微信提供 RESTful API（如统一下单接口 https://api.mch.weixin.qq.com/v3/pay/transactions/jsapi）。
3. SDK层：微信官方提供 SDK（如 tenpay 库），封装了签名生成、请求发送等逻辑。
4. 框架层：你在 Spring Boot 框架中调用 SDK，处理业务逻辑。
5. 应用层：用户在小程序前端触发支付，后端通过 SDK 完成支付流程。

4. 扩展学习方向

• API 设计风格：RESTful、GraphQL、SOAP。
• API 管理工具：Postman、Swagger（OpenAPI）。
• SDK 分发方式：包管理器（npm、pip）、动态加载（CDN）。
• 协议优化：如何选择 HTTP/2、gRPC 或 WebSocket。

总结

• API 是交互的接口，SDK 是开发的工具箱，Library 是工具，Framework 是脚手架。
• 理解这些概念的关系，能帮助你在技术选型时更清晰地判断：
  • 是否需要直接调用 API？
  • 是否有现成 SDK 可用？
  • 是否应该基于某个框架开发？