Translated by
2019/08/12 21:58:50

Application Programming Interface (API)

Application programming interface (Application Programming Interface, API [eypiay]; in Russian say [ap]) more often — a set of methods (functions) which the programmer can use for access to functionality of a program component (programs, the module, library). API is the important abstraction describing functionality "in pure form", irrespectively how this functionality is implemented.

Content

API as integration tool of applications

API defines functionality which is provided by the program (the module, library), at this API allows to abstract from that, how exactly this functionality is implemented.

If the program (the module, library) to consider as a black box, then the set of "handles" which are available to the user of this box which it can twirl and pull is API.

Program components interact with each other by means of API. At the same time usually components form hierarchy — high-level components use API of low-level components, and those, in turn, use API of even more low-level components.

By such principle data transfer protocols are constructed on Internet. Standard Internet protocol (network model of OSI) contains 7 levels (from the physical layer of transfer of packets of bits to the level of protocols of the applications similar to protocols HTTP and IMAP). Each level uses functionality of the previous transmission level of data and, in turn, provides necessary functionality to the following level.

It is important to notice that the concept of the protocol is faithful to the concept API. Both is abstraction of functionality, only in the first case it is about data transmission, and in the second — about creation of computer applications.

API libraries of functions and classes are included by the description of signatures and semantics of functions.

Application Programming Interface (API) the program interface of interaction between systems allowing:

  • Get access to business services of the enterprise
  • Communicate between systems and applications
  • Simplify interaction between the companies, partners, developers and clients

Open API strategy

Strategy includes API:

  • Development of business products on the basis of the existing API
  • Providing internal services to developers
  • Models of monetization of API for creation of multi-channel interaction and increase arrived

Implementation of the concept of Open API helps to transform business, to build in it a flexible project ecosystem of players of the market, to create conditions for permanent generation of the new ideas and formation of additional value at management of arrays of corporate data.

The market of integration solutions develops in the context of evolution of API - EDI SOAP completely Web 2.0 with which the era of public API began. The number of such interfaces in the next 3 years can grow more than in the 50th time and reach 1 million. It is connected with a multikanalnost: channels of customer interaction should change together with them. Continuous growth of number of consumers and amount of data led to emergence of economy of API helping to create the innovation business models of use of corporate assets and services on the basis of open interfaces.

Function signature

Function signature — the part of the general function declaration allowing means of broadcasting to identify function among others. In different programming languages there are different ideas of a function signature what is also closely connected with function overloading opportunities in these languages.

Sometimes distinguish a signature of a call and a signature of implementation of function. The call signature usually is formed on a syntactic construction of function call taking into account a signature of area of visibility of this function, function name, the sequence of the actual types of arguments in a call and type of result. Some elements from a syntactic construction of function declaration usually participate in an implementation signature: qualifier of area of visibility of function, her name and sequence of formal types of arguments.

For example, in the Si programming language ++ simple function is unambiguously identified by the compiler on her name and the sequence of types of her arguments that makes a function signature in this language. If function is method of some class, then the class name also will participate in a signature.

In the Java programming language the method signature is made by his name and the sequence of types of parameters; the value type does not participate in a signature.

Semantics of function

Semantics of function is a description of what this function does. Semantics of function includes the description of what is result of function evaluation as well as what this result depends on. Usually the result of accomplishment depends only on values of function arguments, but in some modules there is a concept of a status. Then the result of function can depend on this status, and, besides, state change can become result. The logic of these dependences and changes belongs to semantics of function. A complete description of semantics of functions is the executable code of function or a mathematical definition of function.

API of operating systems. The problems connected with variety of API

Practically all operating systems (Unix, Windows, MacOS, etc.) have API using which programmers can create applications for this operating system. The main API of operating systems is a set of system calls.

In the software industry the general standard API for standard functionality have an important role as they guarantee that all programs using the general API will work equally well or, on extremely measure, a typical usual image. In case of API of graphical interfaces it means that programs will have the similar user interface that facilitates process of mastering of new software products.

On the other hand, differences in API of different operating systems significantly complicate transfer of applications between platforms. There are different methods of a bypass of this complexity — writing "intermediate" API (API of the graphical interfaces Qt, Gtk, etc.), writing of libraries which display system calls of one OS in system calls of other OS (such environments of execution as Wine, cygwin, etc.), introduction of coding standards in programming languages (for example, standard [[Si language C), writing of the interpreted languages implemented on different platforms (sh, [[perl|library Si of language C), writing of the interpreted languages implemented on different platforms (sh, perl, php, tcl, Java, etc.)

It is also necessary to note what often is at the disposal of the programmer several different API allowing to achieve the same result. At the same time each API is usually implemented using API program a component of lower level of abstraction.

For example: to see in the browser a line "Hello, world!" it is only enough to create HTML document with the minimum heading, and the simplest body containing this line. What will occur when the browser opens this document? The program browser will transfer the file name (or already open file descriptor) to the library processing HTML documents, that, in turn, through API of the operating system will read this file, and will understand its device, povyzyvat through API libraries of standard graphic primitives of transaction like "clean a window", "write the selected font Hello, world!", at these transactions the library of graphic primitives will make to library of a window interface the corresponding inquiries, already this library will make to API of the operating system type inquiries "and put to me in the video card buffer this".

At the same time practically on each of levels really there are several possible alternative API. For example: we could write the initial document not in HTML, and on LaTeX, for display could use any browser. Different browsers, generally speaking, use different HTML-libraries, and, besides, all this can be collected (generally speaking) using different libraries of primitives and on different operating systems.

The main difficulties of the existing multi-layer systems of API, thus, are:

  • Complexity of porting of a program code from one API system on another (for example, when changing OS);
  • Loss of functionality upon transition from lower level to higher. Roughly speaking, each "layer" is created by API for simplification of accomplishment of some standard set of transactions. But at the same time really is at a loss, or there is essentially impossible accomplishment of some other transactions which are provided by lower level of API.

Main API types

Internal API

  • Access to API is provided only to internal developers
  • Applications are aimed at the staff of the enterprise

Business drivers:

  • Consistency of development
  • Cost reduction
  • Increase in efficiency of development

Partner API

  • API are available only to limited set of business partners
  • Applications are intended for end consumers and for business users

Business drivers:

  • Development process automation
  • Partnership development
  • Process optimization of partner interaction

Public API

Access is provided to any external developer Applications are aimed at end users

Business drivers:

  • Development of new services
  • Development of an ecosystem
  • Multi-channel interaction

The most known API

API of operating systems

API of graphical interfaces

API of sound interfaces

API of the authentication systems

Principle and use of API Economy

Magic quadrant of Gartner for Full Life Cycle API Management, October, 2016.
Magic quadrant of Gartner for Full Life Cycle API Management, October, 2016.

API are a link which does by reality cloud computing. API are a basic layer for digital transformation. And API saved billions of dollars of costs for integration and human resources. API define how software interacts and as there is a data exchange. In many respects API move the world of technologies.

But API also create problems. First, there is a spontaneous reproduction of API as each company creates them just to look fashionable (API for self-advertisement?). Further, there is a quality problem. Not any company well supports the API. Naturally, is available decently the vendors aiming to help you to manage all these API (look at a magic quadrant of Gartner).

What to be guided in practice by? [1] in several research zameta of Gartner the following hints[2] are given[3].

  • Work on API should have the measured value. Do not spend resources for creation of API which any developer will not use.
  • Create API only if it will have a specific user. Should be the partner or an ecosystem which need him.
  • The medium-sized enterprise always uses more API, than creates independently. Its divisions will deal with a set of API, and on CIO the task it lays down to manage.
  • API are critical for Internet of Things, opportunities of ordinary users, analytics and information systems. If, creating API, you forget about these things, properly think.

Principle of API Economy
Principle of API Economy
Use of API opens new opportunities of interaction with an ecosystem
Use of API opens new opportunities of interaction with an ecosystem

API allow the organizations to create the personalized user interaction

Expectations and behavior of buyers change[4][5]

Buyers:

  • Require the individualized approach – on their conditions
  • Expect the complex integrated service
  • Pereydutk to any who will better meet their requirements

Organizations:

  • Interact with customers via the interativny websites, mobile applications and other friendly digital interfesa created for this purpose
  • Expect the complex integrated service
  • Will pass to any who will better meet their requirements

API everywhere!

  • According to the experts, by the end of decade more than 1 million public API IBM will be available to users[6]
  • According to the statistics, more than 9 million developers are involved in creation of internal API. Today focus moves towards development of public[7]
  • Internet of Things (IoT) will reach 20 billion attached devices by 2020[8]
  • Google in 2016 paid 625 mln. dollars for purchase of the supplier of the platform of management of API of Apigee company.
  • As the head of the center of consulting Aplanaamelin Vladimir told, in 2016 the number of the published Public API around the world reached 16 thousand, and by their 2020 there will be already more than 1 million. In Russia they are provided to "Yandex", Mail.ru, by VKontakte, Odnoklassniki, in the financial sphere — Sberbank, FC Otkrytiye, Tinkoff Bank, VTB and also large retail networks, services of state services and the open government. According to the conducted survey, 26% of domestic banks were developed or develop own API, another 38% are going to make it next year. According to Gartner, 75% of banks from the world Top 50 list already have own open API, and by 2018 regulators of a half of the countries of the G20 will adopt the standards regulating their application. A kind of Public API are the interfaces of category Open API which are based on open standards and available to a wide range of developers, as a rule, on a free basis. According to Vladimir Amelin, growth of their popularity is connected with the fact that more and more companies see in them the potential for deployment of new business models and understand how to monetize such models.

Chronology of events

2019

The industry of securities is ready to API

On August 2, 2019 it became known that joint survey SWIFT and BCG revealed growth of use API against the background of aspiration of the companies to increase in efficiency and service offering.

Services industry of security market is close to a turning point in implementation of program interfaces of applications (API) in the conditions of aspiration of firms to increase in efficiency and implementation of modern business models.

According to poll of BCG, only during 2018 the awareness on API among asset managers increased by 26% (from 46% to 72%). The growing commercial interest stimulates pilot schemes and scenarios of application, especially between management companies and their custodians.

API are capable to help the industry of securities to cope with numerous and various asset types, difficult information exchange and the growing pressure of the commissions. Four areas in which API can bring benefit to all industry are given in the report:

  • Efficiency and economy of means at the expense of the automated data exchange
  • Information access in real time, for example, to the status of calculations and intra day risk
  • Additional services: the enriched data and analytics
  • The operational indicators allowing service providers to compare efficiency among players in the market

In the industry of securities implementation of API happens more slowly, than in other spheres of financial services partially due to the lack of a regulatory framework and the insufficient sequence in readiness of players of the market to accept API. Asset management companies significantly differ on the technical equipment and openness for interaction with providers through API. About 56% of respondents in poll of BCG consider the level of implementation of API in post-trading "experimental" while only 21% say that it "high" or "average".

«
API can become a powerful incentive for implementation of innovations in post-trading as it was in the industry of payments and in other spheres of banking activity. Interest in this technology grows, and the first results of experiments look promising. But really to stimulate and accelerate widespread introduction of API, we need to eliminate uncertainty concerning standards and to improve understanding of a maturity of technology,
noted Juliette Kennel, the head of department of securities and foreign exchange markets in SWIFT
»

Four reasons for which the industry should implement API are given in the report:

  • Interaction within the general infrastructure. Such fundamental elements of API solutions as the identity certificate, authentication, security and management of network connections, should be approved at the industry level, but not between separate firms.
  • Coordination of the API standards for maintenance of compatibility. Distribution of a set of standards can reduce efficiency of use of API. The industry needs the uniform API standard which will work between all providers.
  • Support of network API, but not p2p-solutions. Firms can benefit from network API: for example, one call for check of the status of calculation from the broker dealer can be sent to several custodians at the same time. The network solution will support convergence both for an explanation of data, and for other characteristics of API.
  • Compliance to strict standards of security and stability. For successful development any API solution should have the high level of data protection and stability.

«
API acted as one of key technologies in digital transformation of all banking sector. Now API gets into the industry of service of securities and becomes a dominant technology among the companies which aim to pass to digital service. Despite the existing difficulties for acceptance of API regarding interoperability and security, we believe that they will be overcome and we expect further implementation of technology in the near future,
told Sumitra Kartikeyan, the head of department of service of securities in BCG
»

«
Implementation of API in security market based on SWIFT is capable to provide achievement of such key purposes as cost reduction and creation of additional business opportunities for market participants and, especially, for management companies and final investors. Therefore the NSD studies application of open API and actively cooperates with SWIFT in issues of standardization of API technology and practical use of this technology in global post-trading,
»

API of European Banks were not ready to fulfillment of requirements of PSD2

On July 10, 2019 it became known that against the background of rapid approach of the date of entry into force of the normative technical standards (Regulatory Technical Standards, RTS) which are the cornerstone of Directive PSD2, representatives the Swedish of the open bank Tink platform say that the European credit institutes did not manage to provide to third-party suppliers the technology environment necessary for access to payment to data as that is required by the appeared law. In more detail here.

See Also