Plugins
API7 Enterprise plugins extend API7 Enterprise's functionalities to meet organization or user-specific requirements in traffic management, observability, security, request/response transformation, serverless computing, and more.
API7 Enterprise offers many plugins that can be customized and orchestrated to satisfy your requirements. These plugins can be globally enabled on every incoming request, or locally bound to other objects, such as routes, services, or consumers.
If existing API7 Enterprise plugins do not meet your needs, you can also write your own plugins in Lua or other languages such as Java, Python, Go, and Wasm.
Plugins Execution Lifecycle
The configuration of the plugin is then checked against the defined JSON Schema to make sure the plugins configuration schema is correct.
When a request goes through API7 Enterprise, the plugin's corresponding methods are executed in one or more of the following phases: rewrite
, access
, before_proxy
, header_filter
, body_filter
, and log
. These phases are largely influenced by the OpenResty directives.
![Routes Diagram](https://static.apiseven.com/uploads/2023/03/09/ZsH5C8Og_plugins-phases.png)
To learn more about phases for your custom plugins development, see the plugin development how-to guide (coming soon).
Plugins Execution Order
In general, plugins are executed in the following order:
Plugins in global rules
- plugins in rewrite phase
- plugins in access phase
Plugins bound to other objects
- plugins in rewrite phase
- plugins in access phase
Within each phase, you can define a new priority value in the _meta.priority
attribute of the plugin, which takes precedence over the default plugins priority during execution. Plugins with higher priority values are executed first.
Plugins Merging Precedence
When a plugin is configured both globally in a global rule and locally in an object (such as a route), both plugin instances are executed sequentially.
However, if a plugin is configured locally on multiple objects, only one copy of configuration is used. During execution, plugins configured in these objects are merged in a specific order of precedence:
Consumer
> Route
> Service
Therefore, if a plugin has different configurations in different objects, the plugin configuration with the highest order of precedence will be used.
Plugins Execution Filter
By default, all plugins are triggered by incoming requests that match the configured rules in routes. Sometimes you may want more granular control over plugins execution.
API7 Enterprise allows dynamic control over plugin execution by applying the _meta.filter
configuration to the plugins. The configuration supports the evaluation of a wide range of built-in variables and API7 Enterprise expressions.
Plugin Global Rules
A plugin global rule object is used to create plugins that are triggered on every incoming request. Global rules will be executed before other plugins locally bound to objects. Certain plugins, such as rate limiting and observability plugins, are frequently enabled globally to provide consistent and comprehensive protection for APIs.
This diagram illustrates how to enable the prometheus
plugin globally for incoming requests and enable proxy-rewrite
plugin on a route to modify the request's HTTP header.
This example enables two different plugins as a global rule and on a route. If the same plugin is configured on both objects, the plugin will be executed sequentially.
Plugin Metadata
A plugin metadata is used to configure the common metadata fields of all plugin instances sharing the same plugin name. It is useful when a plugin is enabled across multiple objects and requires a universal update to their metadata fields.
The following diagram illustrates the concept of plugin metadata:
Without specified, the log_format
on the plugin metadata object should apply the same log format uniformly to both syslog
plugins. However, since the syslog
plugin on the /order
route has a different log_format
, requests to this route will generate logs in the log_format
specified by the plugin in route.
If a plugin field is defined in both the plugin metadata and another object, the definition on the object takes precedence over that in plugin metadata.
Plugin metadata objects should only be used for plugins that have metadata fields. For more details on which plugins have metadata fields, see the plugin reference guide (coming soon).