You're
viewing Apigee X documentation.
View Apigee Edge documentation.
With ConfigurablePREVIEW API proxies, API developers can quickly create and deploy a lightweight proxy using a declarative configuration model. In the configurable proxy configuration model, users specify the intended behavior of the proxy, instead of the sequential instructions required produce the behavior.
Programmable versus configurable proxies
Apigee's familiar XML-based proxy configuration, or the "programmable" configuration model, allows users to program imperatively. That is, a programmable API proxy configuration specifies sequential instructions to control the flow of conditional logic and the state of each request and response. This is used to orchestrate complex operations with multiple data sources, execute decision making logic, or import custom code.
For example, to perform external callout processing in a programmable (imperative) Apigee API proxy, an API developer specifies each of the following instructions:
- Call an external service.
- If the response contains
foo, then call endpoint X. - If the response contains
bar, then call endpoint Y.
The ConfigurablePREVIEW API proxy (declarative) model enables the API developer to easily provide a set of instructions that describe desired outcomes, rather than prescribing how to achieve those outcomes. While imperative logic such as sequential conditions or loops are not supported, there are many rules that follow this model, such as:
- Allow or deny rules
- Token verification rules
- Quota enforcement rules
The use of industry-standard YAML syntax, such as anchors and extensions, make it easy for API developers to quickly get up and running without learning a product-specific language. The configurable API proxy offers standard API gateway features for high volume traffic, including:
- Support for API keys to access API products
- OAuth 2.0 and JWT authentication
- Rate limiting
- Callouts to external policy decision points
- Simple payload transformations (ex. gRPC to JSON)
Key benefits
With ConfigurablePREVIEW API proxies, API developers can implement standard API gateway features, with reduced configuration required for common behaviors like API key verification, JWT authentication, and CORS settings
Comparing features
The following table compares the gateway capabilities of the two configuration formats:
| Feature | Environment Type | |
|---|---|---|
| Proxy Format | PROGRAMMABLE (XML) | CONFIGURABLE (YAML) |
| Deployment Type | ARCHIVE
PROXY |
ARCHIVE
N/A |
| Security Features | ||
| OAuth - Generate Tokens | Yes | N/A |
| OAuth - Validate Tokens (JWT) | Yes | Yes |
| OAuth - Validate Tokens (opaque) | Yes | No |
| Verify API Keys | Yes | Yes |
| IP and CIDR allow/deny lists | Yes | NA |
| Advanced Security
(JWS, HMAC, SAML, XML/JSON Threat Protection, RegEx Scans) |
Yes | No |
| Traffic Throttling | ||
| Quota | Yes | Yes |
| SpikeArrest | Yes | N/A |
| Payload Manipulation | ||
| Programmability | Yes | No |
| GraphQL | Yes | No |
| SOAP ←→ REST or XSLT | Yes | No |
| Schema validation
[WSDLs, GraphQL, OAS] |
Yes | N/A |
| JSON ←→ gRPC | No | N/A |
| Flow Control/Decisions | ||
| Callouts | Yes [Via Service Callout or External Callout] |
N/A |
| Cache and KVM | Yes [Apigee cache or Cloud CDN] |
N/A |
| Upstream/Southbound Connectivity | ||
| Target Servers | Yes | Yes |
| Target URIs | Yes | Yes |
| mTLS | Yes | N/A |
| TLS | Yes | Yes |
| Protocols | HTTP 1.0, HTTP 1.1 | HTTP 1.1, 2.0 |
| Downstream/Northbound Connectivity | ||
| TLS | Yes | Yes |
| Protocols | HTTP 1.1 | HTTP 1.1, 2.0 |
| Request/Response | ||
| Payload limit | 10 MB | N/A [supports larger payloads with product limits] |
| SharedFlows/Flowhooks | Yes | No |
| Advanced Features | ||
| Data Capture | Yes | N/A |
| Monetization | Yes | No |
| API Monitoring | Yes | Yes |
| Developer Portal | Yes | Yes |
| Analytics | Yes | Yes |