This section provides explanations of terms used in the context of Apinizer.

API

An API (Application Programming Interface) is an interface that makes it easy for one application to 'consume' the capabilities or data of another application. By defining stable, simplified entry points to application logic and data, it enables developers to easily access and reuse application logic created by other developers.

Today, APIs are widely used as a contract that determines the structure of communication between client and server in public or local network environment, mobile or Web-based applications. In the context of Apinizer, the word API means server-side Web API with a more limited meaning in this context.


API Management

API management is the entirety of auditing, formatting, deploying, and related actions to APIs in a secure and scalable environment. The purpose of API management is to meet the requirements of API stakeholders with quality and low cost.

API management needs may differ from organization to organization, but core functionality such as API security, monitoring, traffic management and version control are generally common.

Apinizer is an API Management Platform.

API Lifecycle

All steps of an API's life from the idea of creating an API to retiring it compose the API lifecycle. These steps include defining requirements, designing, developing, testing, deploying, meeting security requirements, providing support, monitoring, improving performance and quality, charging and selling the API, updating, versioning, or deprecating a version and responding to customer requests.

Organizations can customize how they operate the steps of the lifecycle based on their needs.

Apinizer supports the API Lifecycle and provides a platform where API Stakeholders can work collaboratively in their own roles.

Click for a summary.

API Stakeholder

Anyone involved in one or more of the API Lifecycle steps is an API Stakeholder.

API Product Manager

It is the role that determines, plans and manages the features that the API Product must provide, its quality requirements, its capabilities, what needs of the customer can be met, its cost and selling price, and how it will be marketed.

API Requirements Analyzer

Determines and documents the requirements of APIs.

API Designer

Designs the details such as parameters, headers, and structure of the messages to be received or returned by the endpoints to be presented by the API, and publishes them as an API Specification in a format that API Developers can understand and use.

API Developer

  • Actually develops the code of the API.
  • Creates and configures API Proxies.
  • Makes configurations to perform integrations.

API Tester

Tests API Proxies with criteria such as functional correctness, performance, security, etc.

API QA Specialist

Continuosly monitors API Proxies or API Products with various criteria such as the level of meeting client needs, operational correctness and performance, detects necessary improvements and provides feedback to API Developers.

API Support Specialist

Evaluates and fixes API Consumer complaints, requests or notifications regarding API Products, creates input for API Developers or API Product Manager.

API Portal Manager

It manages the API Portal application where API Products are delivered to API Consumers.

API Analytics Specialist

Manages and analyzes API logs, creates reports, and provides input to API Product Manager or API Developers collecting metrics such as APIs' overall performance, error frequency, and most problematic or most heavily used APIs so that necessary improvements and adjustments can be made by.

API Security Manager

It performs tasks such as managing client identities, determining which sensitive data to log and how, or connection definitions that require passwords.

API Consumer

Becomes a client to API Proxies or purchases and uses API Products.

Apinizer provides the necessary administrative tools and infrastructure for dynamic role management capabilities to create stakeholders and work collaboratively with other stakeholders.

API Gateway

API Gateway is the common name of software that is used to solve many tasks such as security, logging, traffic management, message conversion, protocol conversion, message verification and many other tasks that are outside the business logic of an API, without touching the API code, by configuring it at an external point. It is put in front of the APIs and the message traffic of the API passes through the API Gateway. Thus, any kind of control, transformation or customization on these messages becomes possible.

Working logic of API Gateway


As seen in the figure, the request sent by the client (Step 1) is met by the API Proxy on the API Gateway. API Proxy is the proxy of the API to be accessed on the API Gateway and the Client actually communicates with the API Proxy. The API Proxy becomes a client to the API (Step 2) and receives the responses returned by the API (Step 3) and returns a response to the Client itself (Step 4).

Through the configurations made with API Gateway software, the behavior of the API Proxy is customized, and thus security, traffic management, message conversions, service transport and similar requirements can be managed from a central point.

Apinizer offers an advanced and easy-to-use, horizontally scalable API Gateway.

API Proxy

It is a proxy entity that is created on API Gateway and imitates the original API. Thus, it is possible to perform various operations before the messages from the client are transmitted to the original API (Backend API) or before the response of the original API is sent to the client.

API Proxy provides a virtualization point for the original API, resulting in a Policy Enforcement Point (PEP).  

API Proxy,

  • is an API Proxy for stakeholders working on API Gateway (API Designer, API Developer, API Tester, etc.),
  • is an API for API Consumers (clients),
  • is an API Product when released by API Product Managers by creating documentation, Sandbox environment access, and pricing plans.

Apinizer provides tools to easily meet the different needs of users, such as importing files to create API Proxy, recognizing API features from URL address, manually adding endpoints, cloning, or progressing with a selection from ready-made definitions.

API Proxy Group

Apinizer allows the creation of API Proxy Groups to collectively manage API Proxies. Thus, the same Policies can be applied to the grouped API Proxies at once, the same settings can be made or all API Proxies can be accessed through the same and single Gateway Address.


Backend API

It is the name of the original API in a scenario that an API Gateway is used. It is closed to the direct access of the client with the API Proxy put in front of it, and instead receives the requests from API Proxy and returns its responses to API Proxy.

Apinizer supports WSDL, Swagger and OpenAPI 3.0 standards, allowing easy creation of API Proxy using the definition files of APIs in these standards. It allows to easily define API/Web Services without definition file or to open API Proxy with Reverse Proxy feature without creating any definition file.

API Definition Files - API Spec Files

They are definition files created for software interpretation that define the structure, functions, header, parameter and return values of an API.

Apinizer supports API Proxy creation using definition files in WSDL, Swagger and OpenApi 3.0 standards. The created API can export the definition files of the proxies in different formats. In addition, with the API Spec Creator tool, it provides the opportunity to create such a definition file through form-based interfaces and convert it to other standard formats.

Mock API

Developing an API to get an application or integration job done can take time. On the other hand, development work on the client side of this API need not wait for the API to be ready. If it is clear which parameters the API will take and how it will return data, an API that will return sample values is sufficient for clients to use by making their own development, for example, for coding user interfaces.

APIs that return predefined or random values generated at runtime to meet this need are called Mock APIs.

Apinizer offers a module where users can quickly and easily create Mock APIs. Users can define conditions on this Mock API and return different responses according to these conditions or apply Policies.

Mirror API

Sometimes, during development or testing, clients need an API that it can be just called, even if it is not functional, and sometimes an API that will return the request it sends as a response to itself. Mirror API is the name given to the API that responds with the request sent to it. Also referred to as the Echo API.

Mirror APIs can be created on Apinizer, and their behavior can be customized by policies.

API Product

APIs are generally used for data sharing, integration or application development purposes. However, especially in recent years, like the applications, APIs themselves have started to be sold for certain fees. In this context, APIs are now produced as a product and follow the life cycle of a product. APIs produced and marketed in this way are called API Products and are usually offered for sale through an API Portal or API Market Place.

Apinizer can ensure that API Proxies on API Gateway are published on the portal as API Product in one step, and documentation and usage statistics are accessible.

API Portal

It is software that API Consumers can access documentation about the APIs offered by a company or institution, test them, use them within certain restrictions, ask and answer questions about them, and become a customer for a fee or free of charge.

Apinizer offers two different API Portal products, one natively integrated with API Gateway, the other a standalone API Portal that can be positioned in front of another API Gateway software if desired, or that can run APIs directly without using an API Gateway.

API Market Place

Individuals or companies that want to develop APIs with their know-how and make money from it, instead of creating their own API Portal by covering higher costs, sell their APIs on the platforms offered by the companies providing this service. Such platforms are called API Marketplace.

Policy

With the configurations made on API Proxy, security, message filtering, validation, conversion or enrichment, partially applying business logic, error management, etc. tasks are managed. These configurations are often referred to as Policies, while the types of policies and how they are handled vary by API Gateway software.

Apinizer offers many policies and gives API Developers full control over the content of request/response messages. Moreover, it saves users from working with complex configuration files by giving the opportunity to do this through interfaces where all configurations can be made form-based.

API Proxy Template

Most of the time, API Proxies within the scope of the same project should work with the same settings, and common settings should not be left to the discretion of the developers. Thus, for example, all API Proxies that are part of an application can work with the same security or error message settings.

With the API Proxy Template, Apinizer makes it possible to automatically apply a set of predefined settings for each new API Proxy.

Local Policy and Global Policy

Local Policy is the name used for Policies that are created while developing an API Proxy and are available only to that API Proxy.

Global Policies are the policies that can be created independently of API Proxies and can be used by multiple API Proxies. A change to a Global Policy affects all API Proxies which use that Policy.

Apinizer allows both Local and Global Policies to be created and used, exported/imported and conversion of a Local Policy to a Global Policy.

Policy Enforcement Point (PEP)

In general terms, it is the name given to virtual points created to enforce the implementation of administrative policies. In the context of API Management, it is the API Proxy object created for policies to be enforced by API Gateway.

Single Point of Entry

API Gateway creates a single entry point for the APIs behind it. Thus, all inspection operations can be done from a single point.

The first question that comes to mind about systems with a Single Entry Point is this: "If there is a Single Entry Point, won't a Single Point of Failure (SPoF) also occur?".

Apinizer creates a Single Entry Point with the API Gateway, but not a Single Point of Failure (SPoF).

Single Point of Failure (SPoF)

A system with a Single Entry Point is referred to as a Single Point of Failure (SPoF) as a problem with that point can make the entire system unusable/unavailable.

Apinizer does not create a Single Point of Failure (SPoF) as it runs on Kubernetes and scales horizontally. 

Condition

Apinizer is capable of operating defined Policies only under certain conditions, or, for example, a Mock API returning a response that meets the specified conditions.

In this context, Condition is a decision definition that is created by using properties such as content, structure or type of any piece of data in a message and checked by API Gateway.

Examples of Conditions:

  • If the request message has a header named username and its value is ABC.
  • If the employeeId parameter of the request message is 1, or the value in this part of the body of the message is 123.

Variable

Apinizer uses Variables to control a Condition or access data in any part of a message. Users can make their own Variable definitions.

Examples of Variables:

header named username 

parameter named employeeId 

Apinizer offers some common Variable definitions predefined.

API Revision and API Version

Development work is an ongoing process. It is normal to make updates, add new Policies or change some settings on API Proxy based on feedback from API Consumers. However, the ongoing development works on an API Proxy should not affect the API Consumers who are actively using the API, and in case of any errors are detected in the new ones, it is necessary to quickly return to the old settings.

For this, API Revisions are created and opened to users after the new revision reaches maturity. A revision should initially contain all the settings of the previous revision, allowing new ones to be made.

Version should not be confused with Revision. Generally, Version means a new API that changes the access address, adds new methods while eliminating some of the old API's methods. In this case, for example, the address of the new version of the API running at https://abc.com/api/v1/blabla would be https://abc.com/api/v2/blabla. In this scenario API Consumers need to update their clients with the address of the new version and any newly added, deleted or updated methods. Such a transition is time-consuming and tiring.

For the Revision, the address of the API does not change, and such large changes are not expected in the methods. Instead, changes are made that are not reflected in API Consumers, such as adding new Policies, that affect the way API Proxy works.

Apinizer allows easy creation of new revisions of any API Proxy and simultaneous deployment of multiple revisions to different Environments (such as Development and Production). It supports how-swap from any revision to any other revision. Since the access address will not change, these transactions are not noticed by API Consumers.

Apinizer also allows versioning. An API Proxy can be cloned and opened from a new address. Since the access addresses are different, two different versions of the same API can be published concurrently.

Environment

Apinizer allows creating as many Environments as desired and different resources can be allocated for these Environments. Thus, it is possible to separate Development & Test, Sandbox and Production environments from each other, as well as to meet varying performance requirements by providing different resources to different client groups. 

Relative Path

The address at which an API Proxy is accessed and generated relative to the root address of the Apinizer installation. It is given when the API Proxy is created and can be updated later. It should be unique for an API Proxy. For example, if a company that opened Apinizer at https://apigateway.abc.com gives the address proxy1 for a new API Proxy, the access address of the endpoints of this API Proxy will be in the form of https://apigateway.abc.com/proxy1/xxx.

Deployment

For an API Proxy to become accessible, it must first be deployed to an Environment on the API Gateway. With the deployment, the settings made for the API Proxy and the added Policies become active. Updates to an installed API Proxy will not take effect until the API Proxy is redeployed. In order to stop access to an API Proxy, it needs to be undeployed.

Apinizer deploys and redeploys API Proxies instantly and invisible to clients, traffic is not stopped.

Publishing

For in-house usage scenarios, it is usually sufficient to deploy an API Proxy and make it available to clients. However, when it comes to the companies that develop API Products and put them into service, these API Proxies must be turned into API Products by documentation, free Sandbox access and pricing plans through API Portal. This is a later step, different from deployment, and is called Publishing. In other words, a "deployed" API Proxy is referred to as an API Product when it is "published".

Apinizer has the ability to publish API Proxies as API Products through API Portal products within its product family.

Logging

In information systems, various log records of the transactions are stored.

  • Log records produced by software codes to record what kind of work is done in which code segment: They are generally used to find an error in the system by setting the levels such as TRACE, DEBUG, INFO, WARNING, ERROR, SEVERE. Apinizer allows changing the level of software logs and querying log records via management interfaces. Thus, there is no need for relatively difficult tasks such as making a server connection, searching, opening and downloading log files for any errors that may occur in the system.
  • Records of the transactions made, who did what when, and how they changed: These are called Audit Records, and the process is called Auditing. Apinizer keeps audit records and allows querying them via management interfaces.
  • Job-specific records: These are the job-specific records made by the information system. For example, a network management system will store records of packets flowing over the network, while a database management system will store records of queries it runs. In this context, Apinizer offers the opportunity to store and manage logs in several different categories:
    • It can store all request/response messages and allows users to specify what is stored and how (see Logging Settings).
    • It stores performance metrics related to message traffic and allows them to be used for purposes such as API Analysis, Anomaly Detection, and step-by-step tracing.
    • Allows users to manage settings for how sensitive data is logged (see Privacy Management).
    • It allows clients to monitor the access keys issued (to whom, when and which key was given).

Log Settings

Apinizer can store all request/response messages passing through it and provides the opportunity to use them for many different purposes.

In addition to the ability to manage which parts of the messages will be logged on the basis of API Proxy, it also provides the ability to set it on a Project basis and valid for all API Proxies.

Privacy Management

Logging the request/response traffic also means logging sensitive data that may be transported in messages. This is not a desired situation. Within the scope of the protection of personal data, it is necessary to take measures such as identifying and not logging sensitive data or logging them by masking, modification or encryption.

Apinizer offers the possibility to configure sensitive data for not to be logged or to be logged by masking, modification, or encryption.

API Monitoring

Continuous monitoring of a system to ensure that the system is working properly, healthy and correctly is called Monitoring. When this operation is done in the context of APIs, it is called API Monitoring.

Apinizer offers 2 different tools and methods for Monitoring:

  • Uptime Monitoring
  • Anomaly Detection

Uptime Monitoring

One or more monitors are defined to ensure that an API is up and running correctly and returns a response within the expected time. These monitors send request messages at specified intervals to the addresses given to them and wait for a response. If the response is not received within the expected time, or if the content of the response is not as expected, it is decided that there is a problem and some actions are triggered.

Uptime Monitoring: Send a Request - Wait for a response in expected criteria


Apinizer allows defining one or more monitors for each of the Backend API, API Proxy or API Products, creating one or more controls for each monitor, and configuring multiple Actions to be executed in case of failure.

Anomaly Detection

One form of monitoring a system is by examining logs. Thus, clients as well as APIs can be monitored. Unexpectedly large messages, temporarily slowing APIs, endpoints with no monitors, or abnormal situations caused by bad configuration can be detected in this way.

Apinizer allows users to create customized queries to run on log records with the help of form-based interfaces. Queries are run at intervals determined by the users, and the results are compared with the threshold values given by the users, and Actions are triggered if these values are exceeded.

Action

Apinizer uses Actions to perform certain tasks by communicating with external systems in certain situations. These actions can be as simple as sending an e-mail, performing a database operation, running a Linux Shell Script, or making an API call to an external system, or they can be user-defined and multi-step Task Flows.

Task Flow

Apinizer has the ability to define Task Flows, which are designed specifically to meet the integration requirements spanning multiple systems, enabling multiple task definitions to be linked and operated like a chain. Thus, for example, it is possible to send an e-mail to someone using the information in certain columns of the records pulled from the database, then make an API call using the information in other columns, write the returned results to another database, and then run a Shell Script. 

Apinizer allows these Task Flows to be run manually, run automatically at specified intervals by defining a timer, linked to another event as an action, or opened as an API over an address.

Connector

There are Connectors in the infrastructure of Action and Task Flows. A Connector provides the ability to connect to another system and run a task.

Apinizer offers various connectors such as database connectors, email connector, API connector, Shell Script connector, JavaScript connector, Groovy Script connector.

Connection Pool

It adversely affects the performance if resources that are costly to create and are recreated after being used for a short process. For this reason, resource pools are created for such resources and these resources are returned to the pool after they are taken from the pool and used. Thus, the performance of the system is improved by eliminating the repetitive creation costs of resources. These pools, which are created especially for connections to database server resources, are called Connection Pools.

Apinizer keeps the performance of its communication with external systems high by managing the connections used by its connectors in connection pools.

API Analytics

In order for the service to be of high quality, the performance and error status of API Proxies must be monitored. Unlike API Monitoring, this monitoring provides a close look at the system's overall usage status with reporting or graphical representations, such as identifying the most heavily used, most error-prone, or latest responding APIs.

Apinizer keeps log records in Elasticsearch, and thanks to the form-based interfaces it provides, creating complex queries, defining API Proxy or endpoint-based reports, and performing full-text searches are all possible without having to know Elasticsearch. More experienced users are free to visualize data with Kibana or Grafana.

Authentication and Identity Management

When an API Proxy is deployed, anyone who knows its address can call any method of that API Proxy. As might be expected, this is not desirable. Therefore, one of the authentication policies (OAuth2, JWT, Basic, Digest, etc.) must be applied for the created API Proxy.The policy applied allows API Gateway to test whether incoming requests are coming from allowed clients. For this test process; information such as username/password, API Key or Access Token received from a specified part of the message must be validated within the valid set of credentials. This process is called Authentication while the process of managing the credentials used during authentication is called Identity Management.

Apinizer offers many authentication methods as policies. In addition, it provides flexible identity management tools that can be used in different ways.

  • Credentials
  • Access Control Lists
  • Authentication Providers

Credentials

Apinizer provides users with the Security Administrator role interfaces to identify clients that can access API Proxies.

Roles can be assigned to the created identities and these identities can be more easily managed by associating them with Organizations. It can be determined which API Proxies it can access for each identity. Identities can be disabled at any time, or they can be automatically disabled at the end of the Agreement/Protocol period by being associated with the Agreement/Protocols. In addition, IP restriction can be made based on identity, quota or throttling can be determined.

In scenarios where the set of clients that can access API Proxies is specific and static, using Credentials provides an easy and high-performance solution.

Credential Roles

Roles are dynamically created and assigned to Credentials. API Proxies, which also use an Authorization policy in addition to the Authentication policy, may expect the client to have some specific roles to access certain endpoints.

Organization

Although access to API Proxies is based on identity in B2B or G2G scenarios, agreements are made with companies or institutions, and APIs are opened to companies or institutions that have made agreements, not individuals. In addition, it should be followed who is authorized to access from that company/institution. Therefore, instead of defining a single identity for the client company/institution, a separate identity is created for each person authorized by this company/institution.

Apinizer names the companies or institutions for which the Credentials are created, as the Organization. It allows Organizations to be defined in a hierarchical manner.

Access Control Lists

The tables prepared by determining which identities can access an entity are called the Access Control Lists.

Apinizer provides interfaces that allow quick and easy configuration of Access Control Lists, such as determining which API Proxies can be accessed based on the Credentials, or selecting the API Proxy and determining who can access it.

Authentication Providers

There may also be scenarios where more dynamic determination of clients is desired. For example, a company may manage which user (client) can access which API with a central application it has developed and store this information in the database, manage its users with software such as LDAP or Active Directory, or perform access control over an API.

Components that provide the set of users or clients that can access a resource and authenticate/enable to authenticate with that set are commonly referred to as the Identity Providers or Authentication Providers.

Apinizer allows common database management systems, LDAP/Active Directory or private APIs to be used as authentication providers.

Contract/Protocol

In B2B or G2G scenarios, APIs are usually made accessible with a contract/protocol and for a period of time.

Apinizer has features such as the ability to manage these contracts/protocols via API Gateway, to track which API is opened to which clients with which contract/protocol, and to automatically close access within the scope of expired contract/protocol, if desired.

Project

In a platform where many stakeholders work collaboratively, various requirements such as user authorization, grouping, management of assets need to be addressed.

Apinizer has adopted Project-based work to meet this need. A Project provides a Workspace where related entities and users are isolated from other Projects. Thus, it is possible for the same users to assume different roles in different projects, and to manage API Proxies, Policies or other definitions on a Project basis.

Team

A team is a group of members working on a project. Teams make it easier to manage members of Projects and roles of users.

Apinizer supports creation of Teams, giving different Roles to members of a Team, or the Team itself, assigning these Teams to Projects, and etc. 

User

It is the name given to the stakeholders who use Apinizer interfaces. With this view, all stakeholders except API Consumers are Users. Users should not to be confused with Clients accessing API Proxies.

Role

It is the name given to the privilege groups.

Apinizer presents certain roles as default values, allowing new roles to be created.

Privilege

In order to a user to do a particular job, he or she must have the privilege for that job.

In the context of Apinizer, Privileges are defined by default and can  be used to create/update Roles. No privilege is assigned to users directly.

DB-2-API

Many applications use APIs developed for database operations that do not require special business logic. Although it is easy to develop such APIs, it is necessary to create a programming environment, work with software developers, upload the developed APIs to a server, and set up a server for this.

With the DB-2-API, Apinizer allows even non-programmers to create and deploy an API that performs database operations in minutes. It supports the following operations:

  • Native SQL statements
  • Stored Procedure calls
  • Returning Cursor result
  • Batch processes

Here's how DB-2-API simplifies and shortens API opening time for database operations:


API Development for Database Operations: Traditional vs. DB-2-API


Script-2-API

Some APIs are created so that an algorithm or a method can be can be accessible by other stakeholders. Algorithm or method may be available or may be newly developed. In either case, doing this in a development environment requires steps such as packing the API and putting it on a server where it will be deployed.

With the Script-2-API, Apinizer allows users to instantly open an API by typing (or pasting) JavaScript or Groovy code. It is also possible to use desired parts of request/response messages within the code. Thus, there is no need to set up a server for the API to be deployed, and the API can be put into service within minutes.