接口开发
API,全称为 应用程序编程接口(Application Programming Interface),是一组定义了不同软件组件之间如何交互的规则和协议。API 允许不同的软件系统通过预定义的接口进行通信,使得开发者能够利用现有的功能和服务,而无需从头开始构建。这种模块化的设计不仅提高了开发效率,还促进了软件生态系统的扩展和创新。
一个典型的 API 包含以下几个关键组成部分:
- 请求(Request): 客户端向服务器发送的调用请求,通常包含请求的方法、URL、头信息和参数。
- 响应(Response): 服务器对客户端请求的返回结果,包含状态码、头信息和数据载体。
- 端点(Endpoint): API 提供的具体功能接口的 URL 地址。
- 方法(Method): 定义在特定端点上可以执行的操作,如 GET、POST、PUT、DELETE 等。
- 数据格式(Data Format): 传输数据的格式,常见的有 JSON、XML 等。
API 根据不同的分类标准可以分为 RESTful API 和 GraphQL API。
特性 | RESTful API | GraphQL |
---|---|---|
端点数量 | 多个端点,每个资源一个 URL | 单一端点 |
数据获取方式 | 固定的资源结构,可能需要多次请求 | 客户端指定数据结构,单次请求即可获取所需数据 |
灵活性 | 较低,资源结构固定 | 高,可动态查询和组合数据 |
缓存机制 | 适用于标准 HTTP 缓存机制 | 缓存策略复杂,需要自定义 |
实时性 | 不支持实时数据推送 | 支持订阅机制,实现实时数据更新 |
学习成本 | 较低,基于 HTTP 标准 | 较高,需要学习 GraphQL 查询语言和概念 |
类型系统 | 无明确的类型系统 | 强类型 Schema,支持类型安全和自动文档生成 |
任何一家公司都可以定义符合自己公司业务需求的 API,但是他们可能使用的都是同一套开发框架在 Python 中,有多种接口开发框架可供选择:
维度 | Flask | FastAPI | Django |
---|---|---|---|
发布时间 | 2010 年 | 2018 年 | 2005 年 |
开发语言 | Python | Python | Python |
架构风格 | 微框架,灵活性高,插件丰富 | 微框架,基于 Starlette 和 Pydantic | 大型框架,支持全栈开发,内置 ORM、Admin 等 |
性能 | 中等,依赖于 WSGI | 高,基于 ASGI,支持异步特性 | 中等,依赖于 WSGI |
异步支持 | 通过扩展支持,如 Quart | 原生支持,使用 async /await | 通过 Django 3.0+ 开始支持异步(仍在逐步完善) |
数据验证 | 依赖扩展(如 Marshmallow 或 WTForms) | 内置 Pydantic,支持强类型和自动验证 | 依赖于表单类(如 Forms 和 DRF 的 serializers) |
自动文档生成 | 需依赖扩展(如 Swagger UI) | 内置支持 OpenAPI 和 Swagger UI | 不原生支持,需依赖 Django REST Framework (DRF) |
学习曲线 | 简单,适合初学者 | 中等,需了解类型注解和异步编程 | 较高,包含多种内置组件,适合系统性学习 |
社区和生态 | 历史悠久,社区活跃,插件丰富 | 新兴框架,社区成长迅速,但生态略小 | 最悠久且成熟,生态完善,适合大型项目 |
可扩展性 | 高,通过插件或定制满足不同需求 | 高,强大的原生功能减少了扩展需求 | 中等,内置组件强大,但灵活性相对较低 |
依赖注入支持 | 无原生支持,需依赖第三方库 | 原生支持依赖注入 | 无原生支持 |
生产就绪 | 成熟稳定,广泛应用于生产环境 | 稳定性较高,但相比 Flask 和 Django 使用年限较短 | 成熟稳定,被广泛应用于大型生产系统 |
调试工具 | 内置基础调试工具 | 支持 Starlette 的调试功能 | 内置调试模式,适合开发测试 |
使用场景 | 中小型项目,快速开发的场景 | 高性能、异步处理或自动文档的场景 | 大型系统开发,支持复杂业务逻辑和多用户系统 |
ORM 支持 | 无原生支持,需借助 SQLAlchemy 等第三方 | 无原生支持,需借助 Tortoise-ORM 等 | 原生支持,提供 Django ORM |
Admin 界面 | 无,需要自行开发 | 无,需要自行开发 | 原生支持,提供强大的 Admin 管理后台 |
支持的 Python 版 本 | Python 2 和 Python 3(旧版支持 Python 2) | Python 3.6+ | Python 3.8+ |
对类型注解的支持 | 不支持,需自行实现类型注解功能 | 原生支持,强类型友好 | 不直接支持,但可结合第三方库使用 |
接口规范
REST API
REST API 是符合 REST(表述性状态转移)架构样式设计原则的 API。 因此,REST API 有时被称为 RESTful API。
EST API 几乎可以使用任何编程语言进行开发,并支持多种数据格式。 唯一的要求是它们要符合以下六个 REST 设计原则 - 也称为架构约束:
- 统一接口。 无论请求来自何处,对同一资源发出的所有 API 请求都应该看起来相同。 REST API 应确保同一条数据(例如用户的姓名或电子邮件地址)仅属于一个统一资源标识符 (URI)。 资源不应过大,但应包含客户可能需要的每一条信息。
- 客户端/服务器解耦。 在 REST API 设计中,客户端和服务器应用程序必须彼此完全独立。 客户端应用程序只需知道所请求资源的 URI 即可; 它不能以任何其他方式与服务器应用程序交互。 同样,除了通过 HTTP 将客户端应用程序传递到所请求的数据外,服务器应用程序不应修改客户端应用程序。
- 无状态。 REST API 是无状态的,这意味着每个请求都需要包含处理它所需的全部信息。 换句话说,REST API 不需要任何服务器端会话。 不允许服务器应用程序存储与客户端请求相关的任何数据 。
- 可缓存性。 如果可能,资源应该可以在客户端或服务器端缓存。 服务器响应还需要包含有关是否允许对交付的资源进行缓存的信息。 目标是提高客户端的性能,同时增强服务器端的可扩展性。
- 分层系统架构。 在 REST API 中,调用和响应都会经过多个不同的层。 根据经验,请不要将客户端和服务器应用程序直接相互连接。 通信环路中可能包含多个不同的中介服务器。 需要设计 REST API,让客户端和服务器都无法判断它是与最终应用程序还是中介服务器进行通信。
- 按需编码(可选)。 REST API 通常发送静态资源,但在某些情况下,响应也可以包含可执行代码(例如 Java 小程序)。 在这些情况下,代码只应按需运行。
REST API 通过 HTTP 请求进行通信,以便执行标准数据库功能,例如在资源中创建、读取、更新和删除记录(这些操作也称为 CRUD)。 例如,REST API 可使用 GET 请求检索记录、使用 POST 请求创建记录、使用 PUT 请求更新记录以及使用 DELETE 请求删除记录。 可以在 API 调用中使用所有 HTTP 方法。 精心设计的 REST API 类似于在具有内置 HTTP 功能的 Web 浏览器中运行的 Web 站点。 任何特定时刻或时间戳的资源状态称为资源表示。 几乎可以采用任何格式将该信息传递到客户端,包括 JavaScript 对象表示法 (JSON)、HTML、XLT、Python、PHP 或纯文本。 JSON 非常受欢迎,因为它可以被人类和机器读取,而且与编程语言无关。 在 REST API 调用中,请求头和参数也很重要,因为它们包含重要的标识信息,例如元数据、授权、统一资源标识符 (URI)、缓存、cookie 等。 在精心设计的 REST API 中会使用请求头、响应头和常规 HTTP 状态码。