You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: app/dev-portal/api-catalog-and-packaging.md
+7-4Lines changed: 7 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -97,7 +97,7 @@ flowchart LR
97
97
<!--vale on-->
98
98
99
99
Packaging APIs involves the following steps:
100
-
1. Create an API and attach an OpenAPI spec. Operations from your API's OpenAPI spec should overlap with Routes to ensure requests will be routed to the correct Service. Gateway routing configuration is not directly modified by adding operations.
100
+
1. Create an API and attach an OpenAPI spec. Operations from your API's OpenAPI spec should overlap with Routes to ensure requests will be routed to the correct Service. Gateway routing configuration isn't directly modified by adding operations.
101
101
1. Link a control plane (or control planes) for to allow developer consumption.
102
102
1. Apply the Access Control Enforcement (ACE) plugin globally.
103
103
1. Create an API package by adding operations and package rate limits. Operations are automatically mapped to Routes using your API's OpenAPI spec or you can create them manually. The Gateway configuration isn't directly modified– any unmatched operations will be highlighted to indicate that a user Gateway Manager permissions needs to perform an action.
@@ -130,7 +130,10 @@ rows:
130
130
- setting: |
131
131
`required`
132
132
description: |
133
-
Requires every incoming request to match a defined operation from an API or API package in Dev Portal. If a request doesn't match, ACE rejects the request outright with a 401. All traffic will be rejected except operations or Routes in published APIs linked to an ACE-enabled {{site.base_gateway}}.
133
+
Requires every incoming request to match a defined operation from an API or API package in Dev Portal. If a request doesn't match, ACE rejects the request outright with a 404. All traffic will be rejected except operations or Routes in published APIs linked to an ACE-enabled {{site.base_gateway}}.
134
+
135
+
{:.danger}
136
+
> **Warning:** Setting the `match_policy` to `required` can **block all traffic with a 404**. Any undefined endpoints will be blocked. If you accidentally enable this in your control planes, this could cause a potential outage in production.
134
137
limitations: |
135
138
* Misconfigurations can overexpose unintended Routes.
136
139
* Shuts down all traffic outside of published Dev Portal APIs.
@@ -153,7 +156,7 @@ rows:
153
156
154
157
You can set individual rate limits on an API package as well as operations in that package. Keep the following in mind when configuring rate limits:
155
158
* API package rate limits apply across all operations in the API package **cumulatively**, not individually.
156
-
* Each Operation in an API Package can additionally have an individual rate limit defined. This rate limit applies simultaneously with the rate limiting being counted at the API Package level.
159
+
* Each Operation in an API Package can additionally have an individual rate limit defined. When an operation-level override is present, the package-level limit is ignored for that operation.
157
160
* API package rate limits are applied simultaneously with rate limits from other plugins on gateway entities:
158
161
* Requests that are under the current limit for the Service and API Package will be counted towards both.
159
162
* Requests that surpass the rate limit of an API package won't be counted towards rate limits applied from other rate limiting plugins.
@@ -164,7 +167,7 @@ For example, if you have the following rate limits set:
164
167
***API package A**: 10 requests per second
165
168
***Operation 1**: 5 requests per second
166
169
167
-
A request that is authorized for Operation 1 will count toward both the rate limit for both the API Package A and Operation 1. So, if one request is sent, the authorized application will have nine requests remaining for API Package A and four requests remaining for Operation 1 for the configured time period (per second).
170
+
Because an operation-level override is present, the package-level limit is ignored for that operation. This means a request authorized for Operation 1 will only count toward its specific operation-level limit. So, if one request is sent, the authorized application will have four requests remaining for Operation 1 for the configured time period (per second). The package-level limit of API Package A doesn't apply to this request.
0 commit comments