Chapter 1. 3scale glossary

Admin domain created by the user.

API created by the user. See also Section 1.2.22, “application programming interface”.

See Section 1.1.2, “[Your_API_name]”.

Product created by the user. See also Section 1.17.4, “product”.

Based on Open API Specification (OAS), a 3scale specification for documenting REST APIs from Red Hat 3scale API Management. See also Section 1.2.2, “ActiveDocs”, Section 1.16.2, “OpenAPI Specification”.

Part of the 3scale API Manager, along with System.

See Section 1.21.1, “tenant account”, Section 1.5.2, “developer account”.

Based on Open API Specification (OAS), a 3scale specification for documenting REST APIs created by users. APIs get interactive documentation which makes it easier for developers to understand APIs and also to test them without any installation. See also Section 1.1.5, “3scale API docs”, Section 1.16.2, “OpenAPI Specification”.

Personal token that allow users authenticate against the Account Management API, the Analytics API and the Billing API through HTTP Basic Auth. Users can create multiple access tokens with custom scopes and permissions. See also Section 1.1.5, “3scale API docs”, Section 1.20.2, “service token”.

The central portal for API providers to manage and secure access to their Products. From this portal, API providers can configure the integration of their Product with 3scale, manage their application plans, give access to internal members and external customers, limit traffic per application keys, and customize their Developer Portal. See also Section 1.5.3, “Developer Portal”, Section 1.17.4, “product”.

See Section 1.2.4, “Admin Portal”.

See Section 1.2.22, “application programming interface”.

See Section 1.1.6, “3scale backend”.

Implementation of an API deployed in a host. See also Section 1.2.22, “application programming interface”, Section 1.3.1, “backend”.

An individual, group or company that accesses an API or a product managed by the API provider. The term may refer both to the organization and the software applications written by the organizations to use the API. A given organization may have one or more applications which access the API. See also Section 1.2.12, “API provider”.

See Section 1.2.13, “API key”, Section 1.22.1, “user key”.

See Section 1.2.22, “application programming interface”, Section 1.14.3, “method”.

The entity that owns the APIs and products, and gives access to them by using Red Hat 3scale API Management. An API provider may make their APIs accessible to other teams internally within their organization or externally to third-party developers, partners, or the public. It might include one or multiple tenants. See also Section 1.2.9, “API consumer”, Section 1.21.1, “tenant account”.

A type of credential for an application to be allowed to make calls on a specific API or product. API Keys are a specific type of authentication pattern. See also Section 1.2.22, “application programming interface”.

See Section 1.2.4, “Admin Portal”.

See Section 1.14.3, “method”.

See Section 1.17.4, “product”.

An API gateway based on NGINX used to integrate internal and external APIs with Red Hat 3scale API Management. APIcast is the interface that handles API requests, and depending on its configuration it can handle access control, rate limiting, security filtering, logging, routing, caching, etc. See also Section 1.2.22, “application programming interface”, Section 1.17.4, “product”.

See Section 1.2.17, “APIcast”.

Authentication method working with app identifier. See also Section 1.2.20, “app key”.

Authentication method with app keys. See also Section 1.2.19, “app identifier”.

A piece of software code which is developed to perform some logic. The application will normally have associated to it within the 3scale system a unique set of credentials for the API, a traffic history of the calls sent to the API and meta-data captured at application creation. Applications are linked to developer accounts. See Section 1.2.9, “API consumer”. See also Section 1.5.2, “developer account”.

See also Section 1.1.2, “[Your_API_name]”, Section 1.2.17, “APIcast”, Section 1.2.13, “API key”, Section 1.3.1, “backend”, Section 1.6.1, “endpoint”, Section 1.6.2, “end user”, Section 1.14.3, “method”, Section 1.17.4, “product”, Section 1.20.1, “service”.

The process of verifying the identity of a user or server requesting access to an API or product.

See Section 1.2.9, “API consumer”.

See Section 1.5.3, “Developer Portal”.

See Section 1.17.3, “plugin”.

Pertaining to an entity, such as a feature or supported configuration, that is supported but no longer recommended and that might become obsolete. See also Section 1.19.1, “removed”.

The site where developers can subscribe to APIs. From this site, developers can manage their subscription, have access to their APIs, create applications, access the interactive API documentation, 3scale API docs, see their API consumption, etc. See also Section 1.2.4, “Admin Portal”.

See Section 1.19.1, “removed”.

One end of a communication channel. When an API interacts with another system, the touchpoints of this communication are considered endpoints. See also Section 1.2.22, “application programming interface”, Section 1.3.2, “base URL”, Section 1.14.2, “mapping rule”, Section 1.14.3, “method”.

The user of an application which calls one or multiple products and APIs. See also Section 1.2.22, “application programming interface”, Section 1.17.4, “product”.

Fields displayed when either a new user, application or account is created.

The built-in metric to which all methods report. Additional top-level metrics can be added here in order to track other usage that should not increase the hit count. See also Section 1.14.4, “metric”.

See Section 1.3.2, “base URL”.

Error messages generated by 3scale when calls are performed with an incorrect set of credentials, incorrect IDs, URL addresses, etc. These messages can be errors coming from the application which is calling the API, or they can be a configuration error with the integration of the API with 3scale.

See Section 1.2.4, “Admin Portal”.

Rule that associates incoming calls from specific endpoints to the corresponding methods and metrics created in 3scale. Usage tracking, endpoint access and limits are based on the methods and metrics that are configured with mapping rules. See also Section 1.6.1, “endpoint”, Section 1.14.3, “method”, Section 1.14.4, “metric”.

Allowed interactions -such as GET, POST or DELETE- with an API or a product. Methods are used to track the usage of products and API on 3scale. A method can be added for each of the HTTP methods available on the API endpoints for the API. By default on 3scale, method calls trigger the built-in hits metric. See also Section 1.2.22, “application programming interface”, Section 1.6.1, “endpoint”, Section 1.14.2, “mapping rule”, Section 1.14.4, “metric”.

Track of specific calls to an API. This tracking is done by mapping the calls to one or more URL patterns in the Mapping Rules section of the integration page. Metrics are cumulative and not discrete. The built-in top level metric on 3scale is Hits. Additional top level metrics can be added if needed, and these are considered separately. See also Section 1.9.1, “hit”, Section 1.14.2, “mapping rule”, Section 1.14.3, “method”.

See Section 1.16.2, “OpenAPI Specification”

A standard, language-agnostic interface to RESTful APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection. See also Section 1.1.5, “3scale API docs”, Section 1.2.2, “ActiveDocs”.

Approach for granting access to specific APIs and endpoints, limiting traffic and monetizing API usage. 3scale has different types of plans that can be used on their own or in conjunction, such as Application plans and Account plans.

Developer accounts that trigger traffic limit alerts. These developer accounts could potentially be upgraded to a plan which meets their needs in terms of traffic volume.

A wrapper for the 3scale API that enables API Access Control and API Traffic Reporting without having to run another server. A plugin lives inside the code that powers the API. The plugin calls the 3scale API for access control and traffic reporting.

A bundle of one or more API backends. See also Section 1.1.4, “[Your_product_name]”, Section 1.2.4, “Admin Portal”, Section 1.2.17, “APIcast”, Section 1.2.22, “application programming interface”, Section 1.3.1, “backend”, Section 1.6.2, “end user”.

Pertaining to an entity, such as a feature or supported configuration, that is not available in the product and is no longer supported. See also Section 1.5.1, “deprecated”.

See Section 1.2.22, “application programming interface”.

Key used to authenticate against the Service Management API. These keys are auto generated, unique per service and shared between the users of an account. Use Service Tokens from within the 3scale API docs. See also Section 1.2.3, “access token”.

In 3scale on-premises, the Master Admin Portal considers accounts as tenant accounts. See also Section 1.2.12, “API provider”, Section 1.5.2, “developer account”.

See Section 1.2.20, “app key”.

See Section 1.17.3, “plugin”.

See Section 1.1.1, “[Your_admin_domain]”.