Questo contenuto non è disponibile nella lingua selezionata.
Chapter 2. Installing APIcast
APIcast is an NGINX based API gateway used to integrate your internal and external API services with the Red Hat 3scale API Management Platform. APIcast does load balancing by using round-robin.
In this guide you will learn about deployment options, environments provided, and how to get started.
Prerequisites
APIcast is not a standalone API gateway. It needs connection to 3scale API Manager.
- A working 3scale On-Premises instance.
To install APIcast, perform the steps outlined in the following sections:
2.1. APIcast deployment options Copia collegamentoCollegamento copiato negli appunti!
You can use hosted or self-managed APIcast. In both cases, APIcast must be connected to the rest of the 3scale API Management platform:
- Embedded APIcast: A 3scale API Management installation includes two default APIcast gateways, staging and production. These gateways come preconfigured and ready for immediate use.
Self-managed APIcast: You can deploy APIcast wherever you want. Here is one of the recommended option to deploy APIcast:
- Running APIcast on Red Hat OpenShift: Run APIcast on a supported version of OpenShift. You can connect self-managed APIcasts to a 3scale On-premises installation or to a 3scale Hosted (SaaS) account. For this, deploy an APIcast gateway self-managed solution using the operator.
2.2. APIcast environments Copia collegamentoCollegamento copiato negli appunti!
By default, when you create a 3scale account, you get embedded APIcast in two different environments:
- Staging: Intended to be used only while configuring and testing your API integration. When you have confirmed that your setup is working as expected, then you can choose to deploy it to the production environment.
-
Production: This environment is intended for production use. The following parameters are set for the Production APIcast in the OpenShift template:
APICAST_CONFIGURATION_LOADER: boot,APICAST_CONFIGURATION_CACHE: 300. This means that the configuration will be fully loaded when APIcast is started, and will be cached for 300 seconds (5 minutes). After 5 minutes the configuration will be reloaded. This means that when you promote the configuration to production, it may take up to 5 minutes to be applied, unless you trigger a new deployment of APIcast.
2.3. Configuring the integration settings Copia collegamentoCollegamento copiato negli appunti!
As a 3scale administrator, configure the integration settings for the environment you require 3scale to run in.
Prerequisites
A 3scale account with administrator privileges.
Procedure
- Navigate to [Your_product_name] > Integration > Settings.
Under Deployment, the default options are as follows:
- Deployment Option: APIcast 3scale managed
- Authentication mode: API key.
- Change to your preferred option.
- To save your changes, click Update Product.
2.4. Configuring your product Copia collegamentoCollegamento copiato negli appunti!
You must declare your API back-end in the Private Base URL field, which is the endpoint host of your API back-end. APIcast will redirect all traffic to your API back-end after all authentication, authorization, rate limits and statistics have been processed.
This section will guide you through configuring your product:
2.4.1. Declaring the API backend Copia collegamentoCollegamento copiato negli appunti!
Typically, the Private Base URL of your API will be something like https://api-backend.yourdomain.com:443, on the domain that you manage (yourdomain.com). For instance, if you were integrating with the Twitter API the Private Base URL would be https://api.twitter.com/.
In this example, you will use the Echo API hosted by 3scale, a simple API that accepts any path and returns information about the request (path, request parameters, headers, etc.). Its Private Base URL is https://echo-api.3scale.net:443.
Procedure
Test your private (unmanaged) API is working. For example, for the Echo API you can make the following call with
curlcommand:curl "https://echo-api.3scale.net:443"
$ curl "https://echo-api.3scale.net:443"Copy to Clipboard Copied! Toggle word wrap Toggle overflow You will get the following response:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.4.2. Configuring the authentication settings Copia collegamentoCollegamento copiato negli appunti!
You can configure authentication settings for your API in the AUTHENTICATION section under [Your_product_name] > Integration > Settings.
| Field | Description |
|---|---|
| Auth user key | Set the user key associated with the credentials location. |
| Credentials location | Define whether credentials are passed as HTTP headers, query parameters or as HTTP basic authentication. |
| Host Header | Define a custom Host request header. This is required if your API backend only accepts traffic from a specific host. |
| Secret Token | Used to block direct developer requests to your API backend. Set the value of the header here, and ensure your backend only allows calls with this secret header. |
Furthermore, you can configure the GATEWAY RESPONSE error codes under [Your_product_name] > Integration > Settings. Define the Response Code, Content-type, and Response Body for the errors: Authentication failed, Authentication missing, and No match.
| Response code | Response body |
|---|---|
| 403 | Authentication failed |
| 403 | Authentication parameters missing |
| 404 | No Mapping Rule matched |
| 429 | Usage limit exceeded |
2.4.3. Configuring the API test call Copia collegamentoCollegamento copiato negli appunti!
Configuring the API involves testing the backends with a product and promoting the APIcast configuration to staging and production environments to make tests based on request calls.
For each product, requests get redirected to their corresponding backend according to the path. This path is configured when you add the backend to the product. For example, if you have two backends added to a product, each backend has its own path.
Prerequisites
- One or more backends added to a product.
- A mapping rule for each backend added to a product.
- An application plan to define the access policies.
- An application that subscribes to the application plan.
Procedure
- Promote an APIcast configuration to Staging, by navigating to [Your_product_name] > Integration > Configuration.
Under APIcast Configuration, you will see the mapping rules for each backend added to the product. Click Promote v.[n] to Staging APIcast.
- v.[n] indicates the version number to be promoted.
Once promoted to staging, you can promote to Production. Under Staging APIcast, click Promote v.[n] to Production APIcast.
- v.[n] indicates the version number to be promoted.
To test requests to your API in the command line, use the command provided in Example curl for testing.
- The curl command example is based on the first mapping rule in the product.
When testing requests to your API, you can modify the mapping rules by adding methods and metrics.
Every time you modify the configuration and before making calls to your API, make sure you promote to the Staging and Production environments. When there are pending changes to be promoted to the Staging environment, you will see an exclamation mark in the Admin Portal, next to the Integration menu item.
3scale Hosted APIcast gateway does the validation of the credentials and applies the rate limits that you defined for the application plan of your API. If you make a call without credentials, or with invalid credentials, you will see the error message, Authentication failed.
2.4.4. Deploying APIcast on Podman Copia collegamentoCollegamento copiato negli appunti!
This is a step-by-step guide for deploying APIcast on a Pod Manager (Podman) container environment to be used as a Red Hat 3scale API Management API gateway.
When deploying APIcast on a Podman container environment, the supported versions of Red Hat Enterprise Linux (RHEL) and Podman are as follows:
- RHEL 8.x/9.x
- Podman 4.2.0/4.1.1
Prerequisites
- You must configure APIcast in your 3scale Admin Portal as per Installing APIcast.
To deploy APIcast on the Podman container environment, perform the steps outlined in the following sections:
2.4.4.1. Installing the Podman container environment Copia collegamentoCollegamento copiato negli appunti!
This guide covers the steps to set up the Podman container environment on RHEL 8.x. Docker is not included in RHEL 8.x, therefore, use Podman for working with containers.
For more details about Podman with RHEL 8.x, see the Container command-line reference.
Procedure
Install the Podman container environment package:
sudo dnf install podman
$ sudo dnf install podmanCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Additional resources
For other operating systems, refer to the following Podman documentation:
2.4.4.2. Running the Podman environment Copia collegamentoCollegamento copiato negli appunti!
To run the Podman container environment, follow the procedure below.
Procedure
Download a ready to use Podman container image from the Red Hat registry:
podman pull registry.redhat.io/3scale-amp2/apicast-gateway-rhel8:3scale2.14
$ podman pull registry.redhat.io/3scale-amp2/apicast-gateway-rhel8:3scale2.14Copy to Clipboard Copied! Toggle word wrap Toggle overflow Run APIcast in a Podman:
podman run --name apicast --rm -p 8080:8080 -e THREESCALE_PORTAL_ENDPOINT=https://<access_token>@<domain>-admin.3scale.net registry.redhat.io/3scale-amp2/apicast-gateway-rhel8:3scale2.14
$ podman run --name apicast --rm -p 8080:8080 -e THREESCALE_PORTAL_ENDPOINT=https://<access_token>@<domain>-admin.3scale.net registry.redhat.io/3scale-amp2/apicast-gateway-rhel8:3scale2.14Copy to Clipboard Copied! Toggle word wrap Toggle overflow Here,
<access_token>is the Access Token for the 3scale Account Management API. You can use the Provider Key instead of the access token.<domain>-admin.3scale.netis the URL of your 3scale Admin Portal.
This command runs a Podman container engine called "apicast" on port 8080 and fetches the JSON configuration file from your 3scale Admin Portal. For other configuration options, see Installing APIcast.
2.4.4.2.1. Testing APIcast with Podman Copia collegamentoCollegamento copiato negli appunti!
The preceding steps ensure that your Podman container engine is running with your own configuration file and the Podman container image from the 3scale registry. You can test calls through APIcast on port 8080 and provide the correct authentication credentials, which you can get from your 3scale account.
Test calls will not only verify that APIcast is running correctly but also that authentication and reporting is being handled successfully.
Ensure that the host you use for the calls is the same as the one configured in the Public Base URL field on the Integration page.
2.4.4.3. The podman command options Copia collegamentoCollegamento copiato negli appunti!
You can use the following option examples with the podman command:
-
-d: Runs the container in detached mode and prints the container ID. When it is not specified, the container runs in the foreground mode and you can stop it usingCTRL + c. When started in the detached mode, you can reattach to the container with thepodman attachcommand, for example,podman attach apicast. -
psand-a: Podmanpsis used to list creating and running containers. Adding-ato thepscommand will show all containers, both running and stopped, for example,podman ps -a. -
inspectand-l: Inspect a running container. For example, useinspectto see the ID that was assigned to the container. Use-lto get the details for the latest container, for example,podman inspect -l | grep Id\":.
2.4.4.4. Additional resources Copia collegamentoCollegamento copiato negli appunti!
2.5. Deploying an APIcast gateway self-managed solution using the operator Copia collegamentoCollegamento copiato negli appunti!
This guide provides steps for deploying an APIcast gateway self-managed solution using the APIcast operator via the Openshift Container Platform console.
The default settings are for production environment when you deploy APIcast. You can always adjust these settings for deploying a staging environment. For example, use the following oc command:
oc patch apicast/{apicast_name} --type=merge -p '{"spec":{"deploymentEnvironment":"staging","configurationLoadMode":"lazy"}}'
$ oc patch apicast/{apicast_name} --type=merge -p '{"spec":{"deploymentEnvironment":"staging","configurationLoadMode":"lazy"}}'
For more information, see the: APIcast Custom Resource reference
Prerequisites
- OpenShift Container Platform (OCP) 4.x or later with administrator privileges.
- You followed the steps in Installing the APIcast operator on OpenShift.
Procedure
- Log in to the OCP console using an account with administrator privileges.
- Click Operators > Installed Operators.
- Click the APIcast Operator from the list of Installed Operators.
- Click APIcast > Create APIcast.
2.5.1. APICast deployment and configuration options Copia collegamentoCollegamento copiato negli appunti!
You can deploy and configure an APIcast gateway self-managed solution using two approaches:
See also:
2.5.1.1. Providing a 3scale API Management system endpoint Copia collegamentoCollegamento copiato negli appunti!
Procedure
Create an OpenShift secret that contains 3scale System Admin Portal endpoint information:
oc create secret generic ${SOME_SECRET_NAME} --from-literal=AdminPortalURL=${MY_3SCALE_URL}$ oc create secret generic ${SOME_SECRET_NAME} --from-literal=AdminPortalURL=${MY_3SCALE_URL}Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
${SOME_SECRET_NAME}is the name of the secret and can be any name you want as long as it does not conflict with an existing secret. ${MY_3SCALE_URL}is the URI that includes your 3scale access token and 3scale System portal endpoint. For more details, seeTHREESCALE_PORTAL_ENDPOINTExample
oc create secret generic 3scaleportal --from-literal=AdminPortalURL=https://access-token@account-admin.3scale.net
$ oc create secret generic 3scaleportal --from-literal=AdminPortalURL=https://access-token@account-admin.3scale.netCopy to Clipboard Copied! Toggle word wrap Toggle overflow For more information about the contents of the secret see the Admin portal configuration secret reference.
-
Create the OpenShift object for APIcast
Copy to Clipboard Copied! Toggle word wrap Toggle overflow The
spec.adminPortalCredentialsRef.namemust be the name of the existing OpenShift secret that contains the 3scale system Admin Portal endpoint information.Verify the APIcast pod is running and ready, by confirming that the
readyReplicasfield of the OpenShift Deployment associated with the APIcast object is 1. Alternatively, wait until the field is set with:echo $(oc get deployment apicast-example-apicast -o jsonpath='{.status.readyReplicas}')$ echo $(oc get deployment apicast-example-apicast -o jsonpath='{.status.readyReplicas}') 1Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5.1.1.1. Verifying the APIcast gateway is running and available Copia collegamentoCollegamento copiato negli appunti!
Procedure
Ensure the OpenShift Service APIcast is exposed to your local machine, and perform a test request. Do this by port-forwarding the APIcast OpenShift Service to
localhost:8080:oc port-forward svc/apicast-example-apicast 8080
$ oc port-forward svc/apicast-example-apicast 8080Copy to Clipboard Copied! Toggle word wrap Toggle overflow Make a request to a configured 3scale service to verify a successful HTTP response. Use the domain name configured in
Staging Public Base URLorProduction Public Base URLsettings of your service. For example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5.1.1.2. Exposing APIcast externally via a Kubernetes Ingress Copia collegamentoCollegamento copiato negli appunti!
To expose APIcast externally via a Kubernetes Ingress, set and configure the exposedHost section. When the host field in the exposedHost section is set, this creates a Kubernetes Ingress object. The Kubernetes Ingress object can then be used by a previously installed and existing Kubernetes Ingress Controller to make APIcast accessible externally.
To learn what Ingress Controllers are available to make APIcast externally accessible and how they are configured see the Kubernetes Ingress Controllers documentation.
The following example to expose APIcast with the hostname myhostname.com:
The example creates a Kubernetes Ingress object on the port 80 using HTTP. When the APIcast deployment is in an OpenShift environment, the OpenShift default Ingress Controller will create a Route object using the Ingress object APIcast creates which allows external access to the APIcast installation.
You may also configure TLS for the exposedHost section. Details about the available fields in the following table:
| json/yaml field | Type | Required | Default value | Description |
|---|---|---|---|---|
|
| string | Yes | N/A | Domain name being routed to the gateway |
|
| []networkv1.IngressTLS | No | N/A | Array of ingress TLS objects. See more on TLS. |
2.5.1.2. Providing a configuration secret Copia collegamentoCollegamento copiato negli appunti!
Procedure
Create a secret with the configuration file:
curl https://raw.githubusercontent.com/3scale/APIcast/master/examples/configuration/echo.json -o $PWD/config.json oc create secret generic apicast-echo-api-conf-secret --from-file=$PWD/config.json
$ curl https://raw.githubusercontent.com/3scale/APIcast/master/examples/configuration/echo.json -o $PWD/config.json $ oc create secret generic apicast-echo-api-conf-secret --from-file=$PWD/config.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow The configuration file must be called
config.json. This is an APIcast CRD reference requirement.For more information about the contents of the secret see the Admin portal configuration secret reference.
Create an APIcast custom resource:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow The following is an example of an embedded configuration secret:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Set the following content when creating the APIcast object:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow The
spec.embeddedConfigurationSecretRef.namemust be the name of the existing OpenShift secret that contains the configuration of the gateway.Verify the APIcast pod is running and ready, by confirming that the
readyReplicasfield of the OpenShift Deployment associated with the APIcast object is 1. Alternatively, wait until the field is set with:echo $(oc get deployment apicast-example-apicast -o jsonpath='{.status.readyReplicas}')$ echo $(oc get deployment apicast-example-apicast -o jsonpath='{.status.readyReplicas}') 1Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5.1.2.1. Verifying APIcast gateway is running and available Copia collegamentoCollegamento copiato negli appunti!
Procedure
Ensure the OpenShift Service APIcast is exposed to your local machine, and perform a test request. Do this by port-forwarding the APIcast OpenShift Service to
localhost:8080:oc port-forward svc/apicast-example-apicast 8080
$ oc port-forward svc/apicast-example-apicast 8080Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5.1.3. Injecting custom environments with the APIcast operator Copia collegamentoCollegamento copiato negli appunti!
In a 3scale installation that uses self-managed APIcast, you can use the APIcast operator to inject custom environments. A custom environment defines behavior that APIcast applies to all upstream APIs that the gateway serves. To create a custom environment, define a global configuration in Lua code.
You can inject a custom environment as part of or after APIcast installation. After injecting a custom environment, you can remove it and the APIcast operator reconciles the changes.
Prerequisites
- The APIcast operator is installed.
Procedure
Write Lua code that defines the custom environment that you want to inject. For example, the following
env1.luafile shows a custom logging policy that theAPIcastoperator loads for all services.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create a secret from the Lua file that defines the custom environment. For example:
oc create secret generic custom-env-1 --from-file=./env1.lua
$ oc create secret generic custom-env-1 --from-file=./env1.luaCopy to Clipboard Copied! Toggle word wrap Toggle overflow A secret can contain multiple custom environments. Specify the
–from-fileoption for each file that defines a custom environment. The operator loads each custom environment.Define an
APIcastcustom resource that references the secret you just created. The following example shows only content relative to referencing the secret that defines the custom environment.Copy to Clipboard Copied! Toggle word wrap Toggle overflow An
APIcastcustom resource can reference multiple secrets that define custom environments. The operator loads each custom environment.Create the
APIcastcustom resource that adds the custom environment. For example, if you saved theAPIcastcustom resource in theapicast.yamlfile, run the following command:oc apply -f apicast.yaml
$ oc apply -f apicast.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Next steps
If you update your custom environment be sure to re-create its secret so the secret contains the update. The APIcast operator watches for updates and automatically redeploys when it finds an update.
2.5.1.4. Injecting custom policies with the APIcast operator Copia collegamentoCollegamento copiato negli appunti!
In a 3scale installation that uses self-managed APIcast, you can use the APIcast operator to inject custom policies. Injecting a custom policy adds the policy code to APIcast. You can then use either of the following to add the custom policy to an API product’s policy chain:
- 3scale API
-
Productcustom resource
To use the 3scale Admin Portal to add the custom policy to a product’s policy chain, you must also register the custom policy’s schema with a CustomPolicyDefinition custom resource. Custom policy registration is a requirement only when you want to use the Admin Portal to configure a product’s policy chain.
You can inject a custom policy as part of or after APIcast installation. After injecting a custom policy, you can remove it and the APIcast operator reconciles the changes.
Prerequisites
- The APIcast operator is installed or you are in the process of installing it.
-
You have defined a custom policy as described in Write your own policy. That is, you have already created, for example, the
my-first-custom-policy.lua,apicast-policy.json, andinit.luafiles that define a custom policy,
Procedure
Create a secret from the files that define one custom policy. For example:
oc create secret generic my-first-custom-policy-secret \ --from-file=./apicast-policy.json \ --from-file=./init.lua \ --from-file=./my-first-custom-policy.lua
$ oc create secret generic my-first-custom-policy-secret \ --from-file=./apicast-policy.json \ --from-file=./init.lua \ --from-file=./my-first-custom-policy.luaCopy to Clipboard Copied! Toggle word wrap Toggle overflow If you have more than one custom policy, create a secret for each custom policy. A secret can contain only one custom policy.
Define an
APIcastcustom resource that references the secret you just created. The following example shows only content relative to referencing the secret that defines the custom policy.Copy to Clipboard Copied! Toggle word wrap Toggle overflow An
APIcastcustom resource can reference multiple secrets that define custom policies. The operator loads each custom policy.Create the
APIcastcustom resource that adds the custom policy. For example, if you saved theAPIcastcustom resource in theapicast.yamlfile, run the following command:oc apply -f apicast.yaml
$ oc apply -f apicast.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Next steps
If you update your custom policy be sure to re-create its secret so the secret contains the update. The APIcast operator watches for updates and automatically redeploys when it finds an update.
Additional resources
2.5.1.5. Configuring OpenTracing with the APIcast operator Copia collegamentoCollegamento copiato negli appunti!
In a 3scale installation that uses self-managed APIcast, you can use the APIcast operator to configure OpenTracing. By enabling OpenTracing, you get more insight and better observability on the APIcast instance.
Prerequisites
- The APIcast operator is installed or you are in the process of installing it.
Procedure
Define a secret that contains your OpenTracing configuration details in
stringData.config. This is the only valid value for the attribute that contains your OpenTracing configuration details. Any other specification prevents APIcast from receiving your OpenTracing configuration details. The following example shows a valid secret definition:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create the secret. For example, if you saved the previous secret definition in the
myjaeger.yamlfile, you would run the following command:oc create -f myjaeger.yaml
$ oc create -f myjaeger.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Define an
APIcastcustom resource that specifies theopenTracingattributes. In the CR definition, set thespec.tracingConfigSecretRef.nameattribute to the name of the secret that contains your OpenTracing configuration details. The following example shows only content relative to configuring OpenTracing.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create the
APIcastcustom resource that configures OpenTracing. For example, if you saved theAPIcastcustom resource in theapicast1.yamlfile, you would run the following command:oc apply -f apicast1.yaml
$ oc apply -f apicast1.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Next steps
Depending on how OpenTracing is installed, you should see the traces in the Jaeger service user interface.
Additional resource
2.5.1.6. Setting the APICAST_SERVICE_CACHE_SIZE environment variable Copia collegamentoCollegamento copiato negli appunti!
You can specify the number of services that APIcast stores in the internal cache by adding an optional field in the APIcast custom resource (CR).
Prerequisites
- You have installed the APIcast operator, or you are in the process of installing it.
Procedure
-
Add the
serviceCacheSizeoptional field in thespec:
spec: // ... serviceCacheSize: 42
spec:
// ...
serviceCacheSize: 42
Verification
Type the following command to check the deployment:
oc get deployment/apicast-example-apicast -o yaml
$ oc get deployment/apicast-example-apicast -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Verify inclusion of the environment variable:
... ...
# ... - name: APICAST_SERVICE_CACHE_SIZE value: '42' # ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Additional resource
2.6. Introduction to advanced operation of 3scale API Management APIcast API gateway Copia collegamentoCollegamento copiato negli appunti!
The introduction to advanced operation of 3scale APIcast will help you to adjust the configuration of access to your application programming interface (API).
2.6.1. Public base URL for calls to 3scale APIs Copia collegamentoCollegamento copiato negli appunti!
The Public Base URL is the URL that your API consumers use to make requests to your API product, which is exposed publicly with 3scale. This will be the URL of your APIcast instance.
If you are using one of the Self-managed deployment options, you can choose your own Public Base URL for each of the environments provided (staging and production) on a domain name you are managing. This URL should be different from the one for your API backend, and could be something like https://api.yourdomain.com:443, where yourdomain.com is the domain that belongs to you. After setting the Public Base URL, make sure you save the changes and, if necessary, promote the changes in staging to production.
The Public Base URL that you specify must use a port that is available in your OpenShift cluster. By default, the OpenShift router listens for connections only on the standard HTTP and HTTPS ports (80 and 443). If you want users to connect to your API over some other port, work with your OpenShift administrator to enable the port.
APIcast accepts calls to only the hostname specified in the Public Base URL. For example, if you specify https://echo-api.3scale.net:443 as the Public Base URL, the correct call would be:
curl "https://echo-api.3scale.net:443/hello?user_key=you_user_key"
curl "https://echo-api.3scale.net:443/hello?user_key=you_user_key"
In case you do not have a public domain for your API, you can use the APIcast IP address in the requests, but you still need to specify a value in the Public Base URL field even if the domain is not real. In this case, make sure you provide the host in the Host header. For example:
curl "http://192.0.2.12:80/hello?user_key=your_user_key" -H "Host: echo-api.3scale.net"
curl "http://192.0.2.12:80/hello?user_key=your_user_key" -H "Host: echo-api.3scale.net"
If you are deploying on a local machine, you can specify "localhost" as the domain, so the Public Base URL would look like http://localhost:80, and then you can make requests like this:
curl "http://localhost:80/hello?user_key=your_user_key"
curl "http://localhost:80/hello?user_key=your_user_key"
If you have multiple API products, set the Public Base URL appropriately for each product. APIcast routes the requests based on the hostname.
2.6.2. How APIcast applies mapping rules for capturing usage of 3scale API Management APIs Copia collegamentoCollegamento copiato negli appunti!
Based on the requests to your API, mapping rules define the metrics or designate the methods for which you want to capture API usage. The following is an example of a mapping rule:
This rule means that any GET requests that start with / increment the metric hits by 1. This rule matches any request to your API. While this is a valid mapping rule, it is too generic and often leads to double counts if you add more specific mapping rules.
The following mapping rules for the Echo API show more specific examples:
Mapping rules work at the API product and API backend levels.
Mapping rules at the product level.
- The mapping rule takes precedence. This means that the product mapping rule is the first one to be evaluated.
- The mapping rule is always evaluated, independent of which backend receives the redirected traffic.
Mapping rules at the backend level.
- When you add mapping rules to a backend, these are added to all the products bundling said backend.
- The mapping rule is evaluated after the mapping rules defined at the product level.
- The mapping rule is evaluated only if the traffic is redirected to the same backend the mapping rule belongs to.
- The path of the backend for a product is automatically prepended to each mapping rule of the backend bundled to said product.
Example of mapping rules with products and backends
The following example shows mapping rules for a product with one backend.
The Echo API backend:
-
Has the private endpoint:
https://echo-api.3scale.net Contains 2 mapping rules with the following patterns:
/hello /bye
/hello /byeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
Has the private endpoint:
The Cool API product:
-
Has this public endpoint:
https://cool.api -
Uses the Echo API backend with this routing path:
/echo.
-
Has this public endpoint:
Mapping rules with the following patterns are automatically part of the Cool API product:
/echo/hello /echo/bye
/echo/hello /echo/byeCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
This means that a request sent to the public URL
https://cool.api/echo/hellois redirected tohttps://echo-api.3scale.net/hello. -
Similarly, a request sent to
https://cool.api/echo/byeredirects tohttps://echo-api.3scale.net/bye.
-
This means that a request sent to the public URL
Now consider an additional product called Tools For Devs using the same Echo API backend.
The Tools For Devs product:
-
Has this public endpoint:
https://dev-tools.api -
Uses the Echo API backend with the following routing path:
/tellmeback.
-
Has this public endpoint:
Mapping rules with the following patterns are automatically part of the Tools For Devs product:
/tellmeback/hello /tellmeback/bye
/tellmeback/hello /tellmeback/byeCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Therefore, a request sent to the public URL
https://dev-tools.api/tellmeback/hellois redirected tohttps://echo-api.3scale.net/hello. -
Similarly, a request sent to
https://dev-tools.api/tellmeback/byeredirects tohttps://echo-api.3scale.net/bye.
-
Therefore, a request sent to the public URL
If you add a mapping rule with the
/pingpattern to the Echo API backend, both products - Cool API and Tools For Devs- are affected:-
Cool API has a mapping rule with this pattern:
/echo/ping. -
Tools For Devs has a mapping rule with this pattern:
/tellmeback/ping.
-
Cool API has a mapping rule with this pattern:
Matching of mapping rules
3scale applies mapping rules based on prefixes. The notation follows the OpenAPI and ActiveDocs specifications:
-
A mapping rule must start with a forward slash (
/). Perform a match on the path over a literal string, which is a URL, for example,
/hello.- The mapping rule, once you have saved it, will cause requests to the URL string you have set and invoke metrics or methods you have defined around each mapping rule.
-
Mapping rules can include parameters on the query string or in the body, for example,
/{word}?value={value}). APIcast fetches the parameters in the following ways:
-
GETmethod: From the query string. -
POST,DELETE, orPUTmethod: From the body.
-
-
Mapping rules can contain named wildcards, for example,
/{word}. This rule matches anything in the placeholder{word}, which makes requests such as/morningmatch the mapping rule. Wildcards can appear between slashes or between a slash and a dot. Parameters can also include wildcards. -
By default, all mapping rules are evaluated from first to last, according to the sort order you specified. If you add a rule
/v1, it matches requests whose paths start with/v1, for example,/v1/wordor/v1/sentence. -
You can add a dollar sign (
$) to the end of a pattern to specify exact matching. For example,/v1/wordmatches only/v1/wordrequests, and does not match/v1/word/hellorequests. For exact matching, you must also ensure that the default mapping rule that matches everything (/) has been disabled. - More than one mapping rule can match the request path, but if none matches, the request is discarded with an HTTP 404 status code.
Mapping rules workflow
Mapping rules have the following workflow:
- You can define a new mapping rule at any time. See Defining mapping rules.
- Mapping rules are grayed out on the next reload to prevent accidental modifications.
- To edit an existing mapping rule, you must enable it first by clicking the pencil icon on the right.
- To delete a rule, click the trash icon.
- All modifications and deletions are saved when you promote the changes in Integration > Configuration.
Stop other mapping rules
To stop processing further mapping rules, select the option Last? when you create a new mapping rule, especially after processing one or more mapping rules. For example, if you have defined multiple mapping rules associated with different metrics in the API Integration Settings, such as:
(get) /path/to/example/search
(get) /path/to/example/{id}
(get) /path/to/example/search
(get) /path/to/example/{id}
The rule /path/to/example/search can be marked Last?, then when calling (get) /path/to/example/search, after matching this rule, APIcast stops processing and will not search for matches in the remaining rules, and the metric for the rule (get) /path/to/example/{id} will not be incremented.
2.6.3. How APIcast handles APIs that have custom requirements Copia collegamentoCollegamento copiato negli appunti!
There are special cases that require custom APIcast configuration so that API consumers can successfully call the API.
Host header
This option is only needed for those API products that reject traffic unless the Host header matches the expected one. In these cases, having a gateway in front of your API product causes problems because the Host is the one of the gateway, for example, xxx-yyy.staging.apicast.io.
To avoid this issue, you can define the host your API product expects in the Host Header field in the Authentication Settings: [Your_product_name] > Integration > Settings.
The result is that the hosted APIcast instance rewrites the host specification in the request call.
Protecting your API backend
After you have APIcast working in production, you might want to restrict direct access to your API product to only those calls that specify a secret token that you specify. Do this by setting the APIcast Secret Token. See Advanced APIcast configuration for information on how to set it up.
Using APIcast with private APIs
With APIcast, it is possible to protect the APIs that are not publicly accessible on the internet. The requirements that must be met are:
- Self-managed APIcast must be used as the deployment option.
- APIcast needs to be accessible from the public internet and be able to make outbound calls to the 3scale Service Management API.
The API product should be accessible by APIcast.
In this case, you can set your internal domain name or the IP address of your API in the Private Base URL field and follow the rest of the steps as usual. However, doing this means that you cannot take advantage of the staging environment. Test calls will not be successful because the staging APIcast instance is hosted by 3scale, which does not have access to your private API backend. After you deploy APIcast in your production environment, if the configuration is correct, APIcast works as expected.
2.7. Additional resources Copia collegamentoCollegamento copiato negli appunti!
To get information about the latest released and supported version of APIcast, see the articles: