Application Programming Interface (API)

API as Application Integration Tool

The API defines the functionality that a program (module, library) provides, while the API allows you to abstract from how this functionality is implemented.

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

Software components communicate with each other through APIs. At the same time, components usually form a hierarchy - high-level components use APIs of low-level components, and those, in turn, use APIs of even lower-level components.

According to this principle, protocols for transmitting data over the Internet are built. The standard Internet protocol (network model OSI) contains 7 layers (from the physical layer of bit packet transmission to the layer of application protocols like HTTP and IMAP). Each layer uses the functionality of the previous data layer and, in turn, provides required functionality to the next level.

It is important to note that the concept of protocol is close in meaning to the concept of API. Both are abstractions of functionality, only in the first case we are talking about data transfer, and in the second - about building computer applications.

The function and class library API includes descriptions of function signatures and semantics.

Application Programming Interface (API) software interface between systems, which allows you to:

• Access Enterprise Business Services
• Share information between systems and applications
• Simplify communication between companies, partners, developers, and customers

Open API Strategy

API strategy includes:

• Develop business products based on existing APIs
• Provide internal services to developers
• API monetization models for building multi-channel interaction and increasing profits

The implementation of the Open API concept helps transform the business, integrate it into a flexible project ecosystem of market players, create conditions for the constant generation of new ideas and create additional value in managing enterprise data arrays.

The market for integration solutions is developing in the context of the evolution of APIs - from EDI and SOAP to Web 2.0, from which the era of public APIs began. The number of such interfaces in the next 3 years can grow by more than 50 times and reach 1 million. This is due to multi-channel: customer interaction channels must change with them. The continuous growth of the number of consumers and the volume of data has led to the emergence of the API economy, which helps to create innovative business models for using enterprise assets and services on the basis of open interfaces.

Function signature

A function signature is part of a general function declaration that allows translation tools to identify a function among others. In different programming languages, there are different ideas about the signature of the function, which is also closely related to the possibility of overload of the function in these languages.

Sometimes they distinguish between the call signature and the function implementation signature. The call signature is usually made according to the syntax of the function call, taking into account the signature of the scope of this function, the name of the function, the sequence of actual types of arguments in the call and the type of result. The implementation signature usually involves some elements from the syntax of the function declaration: the function scope specifier, its name and the sequence of formal argument types.

For example, in the C++ programming language, a simple function is uniquely recognized by the compiler by its name and the sequence of types of its arguments, which constitutes the signature of the function in this language. If the function is a method of a class, then the class name will also participate in the signature.

In the Java programming language, the signature of the method is its name and the sequence of parameter types; value type does not participate in signature.

Function semantics

The semantics of a function is a description of what a given function does. The semantics of the function include a description of what is the result of the function calculation, how and on what this result depends. Usually, the result of execution depends only on the values ​ ​ of the arguments of the function, but in some modules there is a concept of state. Then the result of the function may depend on this state, and in addition, the result may be a change in state. The logic of these dependencies and changes refers to the semantics of the function. A complete description of the semantics of functions is the executable code of a function or the mathematical definition of a function.

Main API Types

Internal APIs

• API access is only available to internal developers
• Applications target enterprise employees

Business Drivers:

• Development Consistency
• Lower costs
• Improving Development Efficiency

Partner APIs

• APIs are only available to a limited set of business partners
• Applications for End Users and Business Users

Business Drivers:

• Automate the development process
• Partnership development
• Optimizing Partner Engagement

Public APIs

Access is provided to any external developer Applications target end users

Business Drivers:

• Development of new services
• Ecosystem development
• Multi-channel interaction

Cloud Storage API

Application programming interfaces (APIs) for communicating cloud storage with applications are of various types. A huge amount of web content is built on combining data from various online sources. Once upon a time, this combination was called "mashups" or "Internet 2.0," but today web applications have become part of the modern IT world. Below are storage management APIs that developers can use to provide storage services to^[1] applications^[2]

There is potentially some ambiguity as to what the storage API means. This is due to the fact that in the most general sense, the API is simply code that allows one part of the software to connect to another. For example, if we are talking about "storage APIs," then this may imply APIs provided by the storage array manufacturer to provide monitoring and management of their software products that developers write. Mention may also be made of the web-based localStorage development interface, which allows browser applications to store data locally, and which is considered unsafe. But instead, it is better to consider APIs that provide third-party storage or storage services (databases, lakes, and data warehouses) to which developers can connect through APIs embedded in application code.

Storage APIs can be divided into several categories, including:

• APIs that connect to cloud-based file synchronization services and cloud drives, as well as productivity applications such as Google Workspace or Microsoft 365 via Graph API;
• API for connecting web applications to cloud provider storage services;
• APIs that allow you to use storage-related services, such as databases, lakes, and data warehouses.

When do I use APIs to store data

When connecting through APIs to services such as cloud drives, productivity applications, etc., it means the ability to create, read, update and delete (create, read, update and delete, CRUD) data, usually using HTTP methods such as Get, Post, Put, etc. These are the scenarios that are most suitable for SMB. At the initial level, you can connect to services such as Google Workspace or Microsoft 365 to access files, e-tables, e-mail, documents, calendars, analytics.

In addition, you can connect to cloud storage providers - usually object storage - through APIs to use and manage data according to your business scenario. The enterprise segment also has a wide range of data services available through APIs. These include databases (SQL and NoSQL), as well as higher-level services, often based on them, such as lakes and data warehouses.

Who provides storage APIs and how much they cost

Box and Dropbox offer APIs that allow you to perform many CRUD operations on data stored in their systems based on HTTP, which developers can implement in their applications. They allow you to use different ways to manage files and metadata, as well as organize files. With certain bandwidth limitations, access and API development are free.

Microsoft Graph is a developer API platform that allows you to access a wide range of Microsoft products. The company offers developers a free 365 account. The cost then depends on the number of Graph objects accessed. At the moment, it is $0.375 per 1000 facilities.

Google Workspace (formerly G-Suite) offers API access to a wide range of applications to increase productivity and beyond. This includes access to e-mail, calendars, and e-tables as an elementary database form. There is a free trial subscription, but it lasts only 14 days.

Access to the storage of the main cloud providers - AWS, Microsoft Azure and Google Cloud - is essentially API-based, and Rest and HTTP commands are used. Access to object stores of hyperskalers, such as Amazon S3 and Azure Blob, is carried out using the usual API methods for CRUD operations.

They are often accessed by applications running in the cloud, but not necessarily because APIs provide storage access to applications running elsewhere.

Databases such as AWS RDS (SQL) and DynamoDB (NoSQL) are also accessed through the API. The same can be said about Azure SQL Database and Cosmos DB, as well as NoSQL Cloud SQL and Datastore, which Google offers. In addition, you can use the MongoDB, Scylla, and PostgreSQL databases in the clouds of the big three hyperskalers. All cloud providers have a free level, but it is designed for small companies and developers.

Fauna, DataStax, Couchbase, and MongoDB Atlas offer something similar to cloud point database solutions, sometimes stylized as DBaaS (and usually NoSQL). In addition, the big three offer more complex solutions available through APIs - lakes and storage. These include Azure Data Lake, Amazon Redshift and Google BigQuery.

Operating System API

• Windows API
• POSIX
• Linux Kernel API
• OS/2 API
• Amiga ROM Kernel

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

In the software industry, common standard APIs for standard functionality have an important role, as they ensure that all programs that use a common API will work equally well or at least in the usual way. In the case of graphical interface APIs, this means that programs will have a similar user interface, which facilitates the process of mastering new software products.

On the other hand, differences in the APIs of different operating systems make it very difficult to transfer applications between platforms. There are various methods to circumvent this difficulty - writing "intermediate" APIs (GUI APIs Qt, Gtk, etc.), writing libraries that map system calls of one OS to system calls of another OS (execution environments such as Wine, cygwin, etc.), introduction of coding standards in programming languages (for example, C standard C library), [[C language C), the writing of interpreted languages ​ ​ implemented on different platforms (sh, [[perl|writing interpreted languages ​ ​ implemented on different platforms (sh, perl, php, tcl, Java, etc.)

It should also be noted that the programmer often has several different APIs at his disposal to achieve the same result. At the same time, each API is usually implemented using API software components of a lower level of abstraction.

For example: in order to see the line "Hello, world!" in the browser, it is enough only to create an HTML document with a minimum title, and the simplest body containing this line. What happens when the browser opens this document? The browser will pass the file name (or file handle already open) to the library, processing HTML documents, which, in turn, will read this file using the operating system API, and will be sorted in its device, causes through the API libraries of standard graphic primitives operations such as "clear the window," "write in the selected font Hello, world!," during these operations the library of graphic primitives will turn to the library of the window interface with the corresponding requests, already this library will turn to the operating system API with requests of the form "put this in my buffer of the video card."

At the same time, at almost every level there are actually several possible alternative APIs. For example: we could write the original document not on HTML, but on LaTeX, we could use any browser to display. Different browsers, generally speaking, use different HTML libraries, and, in addition, all this can be (generally speaking) assembled using different primitive libraries and on different operating systems.

The main challenges of existing multilevel API systems are thus:

• The difficulty of porting code from one API system to another (for example, when changing the OS);
• Loss of functionality when transitioning from a lower level to a higher level. Roughly speaking, each API "layer" is created to facilitate some standard set of operations. But at the same time, it really becomes difficult, or it becomes fundamentally impossible to perform some other operations that the lower level of the API provides.

Graphical Interface APIs

• GDI
• GDI+
• Direct3D (Part DirectX)
• DirectDraw (part of DirectX)
• OpenGL
• OpenVG
• X11
• Qt
• GTK
• Motiff
• Tk
• Zune
• SDL

Audio Interface APIs

• DirectSound (part of DirectX)
• DirectMusic (part of DirectX)
• OpenAL

Authentication System API

• BioAPI
• PAM

Principle and use of the Economy API

APIs are the link that makes cloud computing a reality. APIs are the base layer for digital transformation. And APIs saved billions of dollars in integration costs and human resources. It is APIs that determine how software interacts and how data is exchanged. In many ways, APIs are driven by the world of technology.

But APIs also create problems. Firstly, there is a spontaneous reproduction of APIs, since each company creates them simply to look fashionable (API for self-promotion?). Further, there is a quality problem. Not every company supports its APIs well. Naturally, there are decent vendors looking to help you manage all these APIs (take a look at the Gartner magic quadrant).

How can we be guided in practice? Several Gartner research notes give the following hints^[3]

• Work on the API should have measurable value. Don't waste resources creating APIs that no developers will use.
• Create an API only if it has a specific user. There must be a partner or ecosystem that needs it.
• The average enterprise always uses more APIs than it creates on its own. Its divisions will deal with many APIs, CIO and the task is to manage this.
• APIs are critical to the Internet of Things, the capabilities of ordinary users, analytics and information systems. If, by creating an API, you forget about these things, think carefully.

APIs allow organizations to create personalized user interaction

Expectations and behavior of buyers are changing^[4][5]

Customers:

• Require an individualized approach - on their terms
• Expect Comprehensive Integrated Service
• Go to anyone who better meets their requirements

Organizations:

• Interact with customers through interactive web sites, mobile applications and other friendly digital interfaces
• Expect a comprehensive integrated service
• Go to anyone who better meets their requirements

API everywhere!

• Experts estimate that by the end of the decade, more than 1 million ^[6] public APIs will be available to users. ^[7]
• According to statistics, more than 9 million developers are involved in the creation of internal APIs. Today, the focus is shifting towards the development of the public APIs^[8]
• The Internet of Things (IoT) will reach 20 billion connected devices by 2020^[9]
• Google in 2016 paid $625 million to buy Apigee's API management platform provider.
• According to Vladimir Amelin, head of the Aplanaconsulting center, in 2016 the number of Public APIs published worldwide reached 16 thousand, and by 2020 there will be more than 1 million of them. In Russia, they are provided by Yandex, Mail.ru, VKontakte, Odnoklassniki, in the financial sector - Sberbank, Otkritie FC, Tinkoff Bank, VTB, as well as large retail chains, public services and open government. According to the survey, 26% of domestic banks have developed or are developing their own APIs, another 38% plan to do this next year. According to Gartner, 75% of banks on the world Top 50 list already have their own open APIs, and by 2018, regulators of half of the G20 countries will adopt standards governing their application. A variety of Public APIs are Open APIs based on open standards and available to a wide range of developers, usually free of charge. According to Vladimir Amelin, the growth of their popularity is due to the fact that more and more companies see in them the potential for the deployment of new business models and understand how to monetize such models.

Global API Market

Chronology of events

2022: The development of open APIs in Russia will create conditions for the emergence of innovative services and business models

FinTech Association February 14, 2022 presented the results of a study on the application of Open APIs in the Russian financial market "Areas of standardization of Open APIs and their mandatory publication by participants in the financial services market of Russia." The document was prepared jointly with an international consulting company. Accenture

The objectives of the study were:

• Prioritize the scope of the Open API for standard development
• define the approach to the mandatory and advisable provision of APIs by market participants;
• Determine the necessary conditions for the implementation of Open API standards, taking into account both global practice and the views of market participants.

Experts analyzed the international experience and problems of the Russian financial services market in terms of the potential of using Open APIs and gathered the views of consumers and market participants on the demand for new services based on Open APIs and the complexity of their implementation.

The study notes that the development of Open APIs in Russia will create conditions for the emergence of innovative services and business models, the involvement of new players in the financial market, expand opportunities for the development of partnerships and cooperation, reduce costs and risks of integration, including at the cross-industry level.

Open APIs can contribute to the development of a wide range of new solutions in a number of areas, for example:

• exchange of information about the client (with the consent of the client) and his account - for new financial management services in the "single window" (PFM services), personalization of offers and making credit decisions;
• Comparison and selection of financial products on aggregator platforms and marketplaces
• "embedding" financial services and services into third-party platforms;
• seamless payments and transactions with financial products through third-party platforms;
• Identification and customer knowledge as a service for financial institutions.

The study collected estimates of the relevance of Open API applications to consumers and market participants. In addition, estimates of the complexity of implementation by participants in the financial market were taken into account. Based on this, it was proposed to prioritize the implementation of Open API standards.

The full version of the study can be found here.

The study made it possible to consolidate the opinions of participants in the financial market and consumers of financial services regarding the development of Open APIs in Russia and formulate proposals on priorities and approaches to their implementation. Open and non-discriminatory data exchange with the help of Open APIs will contribute to the development of competition in the financial market, as well as to expanding the opportunities for consumers to choose, acquire and use financial products and services, "commented Tatyana Zharkova, General Director of the FinTech Association.

For the purposes of this study, a survey of 1000 individuals and 500 representatives of small and medium-sized businesses in 85 regions was conducted, in-depth interviews and an open survey of 70 participants in the financial market (banks, insurance and investment companies, MFIs, NPFs and fintech players)

2021

SWIFT published API Potential Report

On October 13, 2021, SWIFT in Russia shared the results of a report that examines the potential of APIs and their role in the development of international finance, as well as detailed information on how SWIFT uses APIs as part of its strategy to ensure instant transactions anywhere in the world.

The document provides an overview of the range of API applications for financial market development and SWIFT capabilities for wider use of this technology.

The first API was launched by SWIFT in 2017, in 2020, more than two billion API operations were completed through SWIFT. This is 120% more than in 2019. There are 20 innovative APIs available on the SWIFT developer portal. SWIFT also works with trusted third-party providers from its community who can offer services to users through the SWIFT API channel.

The emergence of open APIs contributed to the dynamic development of the platform economy: thanks to open specifications and business standards for the API, market participants became easier to develop new online services and quickly and cost-effectively respond to its needs. The platform model is very relevant for the financial services industry, where many participants exchange information and are involved in complex transaction flows. APIs can be used to deliver real-time services that are becoming increasingly popular, as they improve customer experience by improving agility, transparency, and efficiency.

APIs have a number of significant advantages for use in financial services: APIs are great for real-time data processing, because they can provide instant data exchange between several applications owned by several owners, they provide the operation of flexible services that are easier to start, support, scale and modify; The API can be quickly marketed, reducing the time to develop new services from months to weeks; APIs provide access to data on demand, have lower cost of ownership, which reduces the capital cost of implementing it, and do not require complex integration.

Open APIs and other third-party tools, along with the availability of public cloud services, have contributed to the development of the platform economy in the past 20 years. The flexibility provided by such an ecosystem creates value for various industries, including financial. In this model, platform owners are responsible for supporting basic infrastructure, market access, security, and management. They offer open APIs, ready-made developer toolkits, and test sites so third-party players can quickly build products, services, and applications, increasing platform capabilities and attracting additional traffic from end users.

The API-enabled platform solution model is very relevant for financial services. In the field of payments, the initial impetus to use the API was given by regulators who sought to increase competition in the banking sector, create equal conditions for new participants and give bank account holders greater control over their data. Today, API-based open banking services are required in an increasing number of countries. The securities industry - with all its complexities and many players - can also benefit significantly from a consistent approach to implementing APIs and platform models.

Banks and other major players in the financial market can play a crucial role in shaping the innovation ecosystem. Using the API, they will manage data, assets, digital identification of customers. Banks can collaborate with small and medium-sized innovative startups, giving impetus to their own development and preventing monopoly behavior by tech giants. By combining financial data with other customer data, banking platforms gain a great advantage in predictive analytics of customer needs.

Although APIs have significant potential for innovative transformation of financial services, difficulties still exist. It is important to overcome such a problem as fragmented API development, which has been aggravated in the financial industry in recent years. When any participant can develop and publish their own API specifications and update them as desired, fragmentation becomes inevitable, and this, in turn, limits the use of APIs to narrow groups of users. This problem is particularly relevant in the financial services industry, where the identification, security, integrity and compatibility of data are of particular importance and cross-border transactions are carried out by several counterparties. Fragmentation is caused by inconsistent business models, differences in identification schemes and security settings, a variety of APIs and their capabilities by organizations, and non-standard data models.

SWIFT is looking for common business standards to ensure API compatibility for financial transactions. The global financial community is on track to adopt ISO 20022 for cross-border payments by November 2025. Regulators require financial institutions to use unified APIs to ensure interoperability of products and services. And SWIFT offers a standardized API approach that is based on consumption and data models, identification, authentication, and Open API specifications.

SWIFT will continue to leverage API capabilities to deliver instant on-demand information and transactional services across its network, becoming an open, two-way platform, and will open access to its more than 11,000 member community to enhanced platform-based API and innovative services available through APIs developed by both the community and third-party providers.

API Security Becomes Top Priority for Enterprises

As follows from the results of the Imvision "API Security is Coming"^[10], as the number of attacks on application programming interfaces grows (APIs), the security associated with their implementation and use is an increasing concern for organization managers, reports the portal ZDNet^[11].

APIs connect various technology services and systems. They can handle requests from clients, work with server-side instructions, and facilitate data collection and processing.

Although the feature sets contained in the API may be of real value to the enterprise market, which is increasingly data-oriented each year, they can also open a new cybersecurity problem for users - it is assumed that attacks using the API will grow in parallel with the further implementation of cloud technologies.

Imvision interviewed more than 100 cybersecurity specialists in the United States and Europe to get an idea of ​ ​ the current state of API security in enterprises. According to the report, 91% of respondents believe that API security should become a priority in the next two years, especially given that more than 70% of corporate organizations are estimated to use more than 50 APIs.

Respondents consider access control (63% of respondents), regular testing (53%), and anomaly detection and prevention (43%) to be the main aspects of API security. In total, 8 out of 10 IT administrators want more control over their organization's API.

However, finding a holistic approach to API security remains a challenge. More than 80% of organizations are estimated to either use or plan to use a centralized API security management solution - for example, the API Management Platform (APIM) - but only a third of respondents believe that their API settings adequately protect them from modern cyber attacks.

Other statistics noted in the report:

• 19% of businesses test their APIs daily for signs of abuse;
• 4 out of 5 organizations allow partners or users to access data using external APIs;
• API strategies currently focus on application performance (64%) and development and integration (58%);
• shadow APIs are considered the most vulnerable, according to 40% of respondents;
• 64% of respondents said that their current solutions do not provide reliable API protection.

As the main barriers to improving API security, companies cited the integration of API solutions with current systems and workflows, as well as providing visibility into the overall use of the API.

2019

TAdviser study together with VTB Bank PJSC with the participation of Skolkovo: API transformation begins in the banking sector of Russia

A survey of 25 banks in the top 100 largest financial organizations in the Russian market showed that 75% of them have already begun or plan to use open APIs. More than 70% of banks expect the regulator to develop standards and recommendations in this area. Prevent API development of risks of confidential data leakage and concerns related to misuse of open information. Russian IT companies have the necessary competencies and are ready to help banks carry out API transformation.

Main article: API transformation begins in the banking sector of Russia

Central Bank invited about 20 banks to participate in the pilot in the field of open APIs

On August 21, 2019, it became known that the Bank of Russia acted as the coordinator of a pilot project in the field of open APIs (software application interfaces) for the integration of bank services within the framework of the Eurasian Economic Union (EAEU). At the time of the release of the material, the Central Bank, together with the central banks of the EAEU countries, is working to prepare the pilot for implementation. About this "Kommersant" told bankers who received the offer of the Central Bank. In total, about 20 credit organizations received a letter from the regulator, which should give an answer about their readiness to participate by August 23. More details here.

Securities Industry Ready for API

On August 2, 2019, it became known that a joint study by SWIFT and BCG revealed an increase in the use of APIs amid companies' desire to increase efficiency and offer services.

The securities market service area is close to a turning point in the implementation of software application interfaces (APIs) in the face of firms' desire to increase efficiency and introduce modern business models.

According to a BCG survey, API awareness among asset managers increased by 26% (from 46% to 72%) during 2018 alone. Growing commercial interest stimulates pilot schemes and application scenarios, especially between management companies and their custodians.

APIs can help the securities industry cope with multiple and diverse types of assets, complex information sharing, and increasing commission pressure. The report lists four areas where APIs can benefit the entire industry:

• Efficiency and cost savings through automated data sharing
• Access to real-time information, such as settlement status and intraday risk
• Operational performance to enable service providers to compare performance among market players

In the securities industry, API implementation is slower than in other areas of financial services, partly due to the lack of a regulatory framework and insufficient consistency in the readiness of market players to adopt APIs. Asset management companies differ significantly in their technical equipment and openness to interact with providers through APIs. About 56% of respondents in the BCG survey consider the level of API implementation in post-trading to be "experimental," while only 21% say it is "high" or "medium."

The API can be a powerful incentive for innovation in post-trading, as it was in the payment industry and in other areas of banking. Interest in this technology is growing, and the first results of the experiments look promising. But in order to really drive and accelerate the widespread implementation of the API, we need to remove uncertainty about standards and improve understanding of technology maturity.

The report provides four reasons why industry should implement APIs:

• Interaction within a common infrastructure. The fundamental elements of API solutions such as identity, authentication, security, and network connection management must be negotiated at the industry level, not between individual firms.
• Coordinate API standards to maintain compatibility. The spread of multiple standards can reduce API utilization. The industry needs a single API standard that will work between all providers.
• Support for network APIs, not p2p solutions. Firms can benefit from network APIs: for example, a single call to check the status of a settlement from a broker-dealer can be sent to several custodians at the same time. The network solution will support convergence for both data explanations and other API features.
• Meet stringent safety and sustainability standards. For successful development, any API solution must have a high level of data protection and sustainability.

API was one of the key technologies in the digital transformation of the entire banking sector. Now the API penetrates the securities service industry and becomes the leading technology among companies that seek to move to digital service. Despite the existing difficulties for API adoption in terms of interoperability and security, we believe that they will be overcome and expect further implementation of the technology in the near future,

The introduction of the API in the SWIFT-based securities market can achieve such key goals as reducing costs and creating additional business opportunities for market participants and, especially, for management companies and end investors. Therefore, NSD studies the application of open APIs and actively cooperates with SWIFT in the standardization of API technology and the practical use of this technology in global post-trading,

European banks' APIs were not ready to meet PSD2 requirements

See also

• Open Data
• Software Development Kit (SDK)