| API |
An API (Application Programming Interface) is the fundamental building block of MWARE ESB. It is an intermediate layer that acts as a communication protocol between a consumer and a service, simplifying the consumption of the service. In addition to hiding the underlying implementation details of a service, an API provides a secure, controlled, and a well-documented approach for accessing the exposed service. |
| API Format |
Open API Specification (OAS, a.k.a Swagger) format is the underneath representation of an API in MWARE ESB. A Swagger definition can be used to import an API to the Publisher Portal. In addition, a user can view, edit, import, or download an API definition in OAS format via the API Publisher Portal. |
| API Resource path and HTTP Methods |
An API is made up of one or more resources, each of which has a unique resource path (URI). An API Resource has a set of HTTP methods that operates on it. The supported HTTP methods are: GET, POST, PUT, DELETE, PATCH, HEAD, and OPTIONS |
| API Lifecycle |
The stages that an API goes through from creation to retirement. APIs have lifecycle stages that are independent of the backend services they rely on. The lifecycle's states are CREATED, PRE-RELEASED, PUBLISHED, BLOCKED, DEPRECATED, and RETIRED. The life cycles of the APIs are customized based on the needs of an organization. |
| Application |
The logical representation of a physical application such as a mobile app, web app, device, etc. For an application to use an API, the application should subscribe to the relevant APIs it intends to use. A subscription to an API happens over a selected business plan, which determines the usage quota the application gets. An application has a consumer-key and a consumer-secret, which acts as the credentials of the application. |
| API Product |
A combination of resources from one or more available APIs. An API product allows API product managers to mix and match resources from the available APIs. Similar to using an API, an application that intends to use an API product needs to subscribe to the APIs under a selected business plan. An application that subscribes to an API product gets access to all of its resources, which belongs to one or more of the APIs that are used to create the API product. |
| Access Token |
Using OAuth2.0 bearer token-based authentication to allow a consumer to access an API. It is a string that is passed as an HTTP header of an API request. MWARE ESB supports JWT formatted self-contained access tokens. The opaque token support is available for the applications that are migrated from older versions. |
| API Visibility |
API visibility determines who can view the API on the Developer Portal. The available visibility levels are as follows: - Public - Visible to all users.
- Restricted by role. - Visible only to the users under the creator's tenant domain who have the relevant roles attached.
- Visible to my domain - Visible to all users who are registered to the API creator's tenant domain. This applies only when there is more than 1 tenant in the system.
|
| Rate Limits |
Rate limiting allows you to limit the number of permitted requests to an API within a given time window. Rate limiting can be useful to - - Protect your APIs from common types of security attacks such as certain types of Denial of Service (DoS) attacks.
- Regulate traffic according to infrastructure availability.
- To apply request quotas for monetization purposes of APIs.
|
| Choreo Connect |
Choreo Connect is an API Gateway for microservices, which is cloud-native, decentralized and developer centric. ESB Choreo Connect is a lightweight message processor for APIs. Choreo Connect is used for message security, transport security, routing, and other common API Management related services. |
| Workflows |
Allows controlling selected user actions on the API Publisher and the Developer Portal. For example, enabling a human approval process to approve users signing up to the Developer Portal. Workflow plugins can be used creatively for other purposes as well, such as performing custom validations, compliance checks, etc. Its asynchronous nature developed on webhooks allows user actions to be put on hold in order to be completed later. |
| Message Mediation Policies |
Message mediation policies are used to enrich, transform, or modify a request or response message that is being routed via the API Gateway. For example, when exposing an XML endpoint as JSON, message mediation policies may be used to convert the message format from XML to JSON and vice versa. These policies can also be used for composing services into APIs and for various other needs such as validations, conformance, etc. |
| Handler |
A handler allows a message to be processed before passing it to the routing logic of the API Gateway. Handlers can be used for security validation, policy enforcement, pushing out events to third party systems, custom logging requirements, etc. A handler allows the processing of both request and response messages. |
| Tags |
Tags allow API providers to categorize APIs that have similar attributes. When a tagged API gets published to the API Developer Portal, its tags appear as clickable links. API consumers can use the link to navigate to a category of interest. API consumers can also search APIs that match a particular tag on the Developer Portal. |
| Tenant |
A tenant in MWARE ESB is a logically isolated entity. A tenant can be mapped as an organizational unit, department, etc. Multi-tenancy enables such organizational units/departments to share the same ESB deployment and the respective resources. However, it functions individually with a personalized view/scope of the installation. Multi-tenancy is popularly used in SaaS offerings. |
| Service Catalog |
Service Catalog is one of the main attributes which enables the API-first Integration in MWARE ESB. Through the Service Catalog, integration services are made discoverable to the API Management layer so that API proxies can directly be created using them. |
| API Publisher Role |
An API publisher (API provider) is an API product manager who manages a set of APIs and API products across the enterprise or business unit and controls the API lifecycle, subscriptions, and monetization aspects of an API or API product. The API publisher can also analyze the usage patterns for the APIs and access all the statistics related to the APIs. |
| API Creator Role |
An API Creator is a person in a technical role who understands the technical aspects of the API (interfaces, documentation, versions, etc.) and uses the API Publisher Portal for the design and development of the APIs. APIs created by an API creator are managed (lifecycle managed and productized) by an API product manager. |
| API Subscriber Role |
A subscriber is a consumer of an API who intends to develop one or more applications that consume APIs on the Developer Portal. A subscriber uses the API Developer Portal to discover APIs, read the documentation and forums, rate/comment on the APIs, subscribe, obtain keys, and finally use APIs from their applications. |
| Admin Role |
The admin user is responsible for managing the Admin Portal, which includes tasks such as approving workflows, managing rate limiting policies, configuring emails for bot detection/alerts, viewing the state and health of APIs, etc. In addition, the admin user is also capable of carrying out general administrative tasks such as managing users, roles, databases, security, etc. |