插件的服务器 API:概述
🌐 Server API for plugins: An overview
Page summary:
服务器 API 定义了插件在 Strapi 服务器上注册、暴露和执行的内容。它包括生命周期钩子、路由、控制器、服务、策略、中间件和配置。使用入口文件声明插件的贡献内容,然后导航到下面为每个功能提供的专用页面。
Strapi 插件可以与 Strapi 应用的前端和后端进行交互。服务器 API 涵盖后端部分:它定义了插件在 Strapi 服务器上注册、暴露和执行的内容。服务器部分在入口文件中定义,该文件导出一个对象(或返回对象的函数)。该对象描述了插件对服务器的贡献内容。
🌐 A Strapi plugin can interact with both the back end and the front end of a Strapi application. The Server API covers the back-end part: it defines what the plugin registers, exposes, and executes on the Strapi server. The server part is defined in the entry file, which exports an object (or a function returning an object). That object describes what the plugin contributes to the server.
有关插件如何自定义管理面板界面的更多信息,请参阅 Admin Panel API。
🌐 For more information on how plugins can customize the admin panel UI, see Admin Panel API.
在深入了解本页的概念之前,请确保你已经创建了一个 Strapi 插件。
🌐 Before diving deeper into the concepts on this page, please ensure you created a Strapi plugin.
入口文件
🌐 Entry file
服务器 API 的入口文件是 [plugin-name]/server/src/index.js|ts。该文件导出所需的接口,提供以下可用参数:
🌐 The entry file for the Server API is [plugin-name]/server/src/index.js|ts. This file exports the required interface, with the following parameters available:
| 参数类型 | 可用参数 || --- | --- || 生命周期函数 | register(), bootstrap(), destroy() || 配置 | config 对象 || 后端自定义 | contentTypes, routes, controllers, services, policies, middlewares |
一个最小的入口文件看起来像这样:
🌐 A minimal entry file looks like this:
- JavaScript
- TypeScript
'use strict';
const register = require('./register');
const bootstrap = require('./bootstrap');
const destroy = require('./destroy');
const config = require('./config');
const contentTypes = require('./content-types');
const routes = require('./routes');
const controllers = require('./controllers');
const services = require('./services');
const policies = require('./policies');
const middlewares = require('./middlewares');
module.exports = () => ({
register,
bootstrap,
destroy,
config,
contentTypes,
routes,
controllers,
services,
policies,
middlewares,
});
import register from './register';
import bootstrap from './bootstrap';
import destroy from './destroy';
import config from './config';
import contentTypes from './content-types';
import routes from './routes';
import controllers from './controllers';
import services from './services';
import policies from './policies';
import middlewares from './middlewares';
export default () => ({
register,
bootstrap,
destroy,
config,
contentTypes,
routes,
controllers,
services,
policies,
middlewares,
});
从技术上讲,所有服务器代码都可以放在单一的入口文件中,但强烈建议将每个关注点拆分到各自的文件夹中,就像插件 SDK 生成的那样。本教程中的示例遵循了这种结构。
🌐 All server code can technically live in the single entry file, but splitting each concern into its own folder, as generated by the Plugin SDK, is strongly recommended. The examples in this documentation follow that structure.
- 入口文件接受对象字面量或返回相同对象形状的函数。当使用函数形式时,Strapi 在加载插件模块时会使用
{ env }(而不是{ strapi })调用它。 config是一个配置对象,而不是可执行的生命周期钩子。与register()、bootstrap()或destroy()不同,它在插件生命周期中不会作为函数被调用。它在启动时加载,用于设置默认值和验证用户配置。有关更多信息,请参见 服务器生命周期。
可用操作
🌐 Available actions
服务器 API 让插件能够利用多个构建模块来定义其服务器端行为。
🌐 The Server API lets a plugin take advantage of several building blocks to define its server-side behavior.
使用下表查找与你的目标相匹配的能力:
🌐 Use the following table to find which capability matches your goal:
| 目标 | 使用的参数 | 运行时间 |
|---|---|---|
| 在服务器启动前运行代码 | register() | 在数据库和路由初始化之前 |
| 在所有插件加载后运行代码 | bootstrap() | 在数据库、路由和权限初始化后 |
| 在关闭时清理资源 | destroy() | 在关闭时 |
| 使用默认值和验证定义插件选项 | config | 启动时加载 |
| 声明插件内容类型 | contentTypes | 启动时加载 |
| 公开 HTTP 端点 | routes | 启动时加载 |
| 处理 HTTP 请求 | controllers | 每个请求调用 |
| 实现业务逻辑 | services | 从控制器或生命周期钩子调用 |
| 在路由上强制执行访问规则 | policies | 在控制器之前按每个请求评估 |
| 拦截并修改请求/响应流程 | middlewares | 附加在 register() 中或在路由配置中引用 |
| 在运行时访问插件功能 | 获取器 | 任何生命周期或请求处理程序 |
以下卡片直接链接到各自的专页:
🌐 The following cards link directly to each dedicated page:
生命周期
通过注册、引导和销毁钩子控制插件服务器逻辑的运行时机。
配置
声明默认插件选项并验证来自 config/plugins 的用户提供的配置。
内容类 型
声明插件内容类型,并通过文档服务 API 在运行时访问它们。
路线
将插件端点暴露为内容 API 或管理员路由,并对身份验证和策略具有完全控制。
控制器与服务
在控制器中处理请求,并在服务中组织可重用的业务逻辑。
策略与中间件
通过策略执行访问规则,并通过中间件拦截请求流。
获取器与使用
通过顶层和全局获取器访问插件控制器、服务、内容类型和配置。
插件的路由、控制器、服务、策略和中间件遵循与标准 Strapi 应用中的后端自定义相同的约定。服务器 API 会自动将这些封装到插件命名空间中(有关 UID 和命名约定的详细信息,请参见服务器内容类型)。
🌐 Plugin routes, controllers, services, policies, and middlewares follow the same conventions as backend customization in a standard Strapi application. The Server API wraps these into the plugin namespace automatically (see server content types for details on UIDs and naming conventions).