“APIBroker”, “APIGateway” or simply, “APIRuntime”<br/><br/>High-performance, scalable, and low latency engine capable of mediatingHTTP requests between API consumers and service enablers;<br/><br/>Cache: Although completely optional to use, many times it is desirable or required to configure caching at the broker level for specific service enabler operation responses. By caching those responses, the broker can improve its responsiveness by reducing the number of requests to an underlying service enabler to whenever its responses are not already cached.<br/>Mediation of high throughput ofHTTPrequests betweenAPI consumers and services;<br/>Awareness and support of Web protocols semantics (MIMEtypes,HTTP Authorization and Caching headers, etc.);<br/><br/>Header transform: modifications of header names and/or header information (e.g., service enabler-specific header to IANA-based header)<br/>Support of Data Format, Data Model transformations and Protocol Bridging between most or all common Web standards (WS-*,SOAP,XML, REST, JSON, etc.);<br/><br/>Parameter transform: modifications of parameter names and/or parameter values<br/>Method transform: modifications of the method specified in API request (e.g., POST to DELETE)<br/>Error information transform: modifications of error information in the body part of API response<br/>Status code transform: modifications of status code in the API response (e.g., 302 “Found” to 303 “See Other”)<br/>Information masking: filtering some information in the API response based on query parameters in API request or based on API provider’s policy<br/>Abstraction: conceptually transformations of the meanings of parameters or decrease of the number of request parameters<br/>Protocol transform: transformations of protocol to send API requests/responses (e.g., SOAP to REST)<br/>Mash-up (Composition): assembling a new API with existing APIs provided by service enabler.<br/>Content-based routing, fail-over, load balancing, and broadcasting of requests;<br/><br/>Route: The broker Route task is the most commonly used task in a broker. A service enabler consumer issues a request to a given service; the broker Route task is responsible for forwarding that request to its underlying service enabler. Beyond the basic behavior of routing, the Route task should allow the parameterization of request timeout, HTTP keep alive connection, HTTP basic or digest authentication, URL decode, HTTP X-Forwarded-For/Host/Server, HTTP referrer, exception shielding configuration, HTTP status code, content based routing by regular expressions or xPath, etc. <br/>Support of standard authentication and authorization protocols (WS-Federation, SAML, OAuth, etc.), for both internal and external applications,APIdevelopers and users;<br/>Validate: The broker Validate task ensures that only valid messages (according to their contract’s schema) are routed to the remote host. This capability lowers dramatically the number of malformed messages that are presented to a given service enabler, and by doing so contributes to maximize the performance and scalability of that service enabler.<br/>Policy, Charging ; Rules Function: The Broker decision task makes it possible to have decision trees within a workflow or policy evaluation, at any nesting level. This is the basis for many possible micro-workflow related activities, making possible to configure a decision point structure where multiple option are present. The values tested in those options can be static or dynamically retrieved at runtime from the broker runtime context or from any part of the currently processed message.<br/>Diagnose: The Broker Diagnose task dynamically updates underlying management systems such as the Windows Management Instrumentation performance counters so that they can be monitored and reported upon by the monitoring service.<br/>Log: The broker Log task enables the logging of any request or response at any time during the processing of a strategy. The task should be able to execute synchronously or asynchronously, and target a designated file system path, database server, HTTP URL, or email address. If configurable to run only for a specific request or response message of a specific user (or user role) the task can be targeted to a specific operation of a specific service enabler. These granularities together with the possibility to deliver the log information in different channels offer great flexibility for both operation and debug scenarios. <br/><br/>CDR: creation of Call Detail Record for calculating API usage fee. <br/>Traffic Control: The broker limits the access from the valid service consumers based on the contract with service consumers or service enablers or based on the conditions of API broker itself or service enablers.<br/><br/>Flow control (Inbound): access limitations based on the contract between API provider and application developers (e.g., throughput/quota/concurrent connections limit)<br/>Flow control (Outbound): access limitation based on the contract between API provider and service enablers or the conditions of service enablers (e.g., throughput/quota/concurrent connections limit)<br/>Application Management: managing account information for recognizing applications (e.g., API key/OAuth2.0’s client_id, client_secret) and application developers. <br/>Data Encryption Key Management: managing data encryption keys to encrypt data in a case of sending sensitive data through API.<br/>Market or Store: In order to accomplish the task of commercial or business mediation, the Broker can implement for itself or communicate to some other external marketplace / store service. For example the broker should be able to count and track requests for any given request or response, and optionally cause the broker to refuse serving any more requests for a specific user if a configured request limit per service consumer or if a configured time frame is reached.<br/>Protect: The broker Protect task may impose access restrictions to some service consumers, in order to protect service enablers from abuse or undesired usage. Some common examples are the configuration of an IP address range restriction or a limit to the maximum message size accepted.<br/><br/>APILifecycle Management application<br/><br/>Supports the processes required for designing, developing, testing, deploying, operating, reporting and retiring APIs;<br/>APICatalog Management: a common database containing metadata related to:API creation driven by project definition templates and configuration wizards,API dependencies registry,APIs earch,API contracts management,API proxies and stubs code-generators, etc.;<br/>Access control policies based on a Role-Based Access Control (RBAC) system that restrict permissions for APIs creation and delivery, thus enabling different stakeholders experiences (for example: Catalog Manager, Service Developer, Service Operator, Service Owner, Product Manager, etc.);<br/>Configuration of allAPI Runtime behaviors (see previous component) using a model-driven language or other type of DSL (Domain-Specific Language);<br/>Real-time monitor and reportQoS(requests per second, exceptions, latency, etc.);<br/><br/>Developers Portal<br/><br/>Technical/commercial API Catalogue;<br/>Easy to search and discover APIs;<br/>API documentation and code examples;<br/>Distribution of API keys and data encryption keys;<br/>Performance and usage reports;<br/>Technical support (online, email, forums, etc.).<br/>
