API: what it is - description and types of API. API Basics

Let's start with the basics: what is an API? The abbreviation stands for Application Programming Interface, or application programming interface. The name seems to speak for itself, but it’s better to consider a more detailed explanation.

As already mentioned, an API is, first of all, an interface. An interface that allows developers to use ready-made blocks to build an application. In the case of mobile application development, the API can be a library for working with " smart home" – all the nuances are implemented in the library and you just access this API in your code.

In the case of web applications, the API can return data in a format other than standard HTML, making it convenient to use when writing your own applications. Third-party public APIs most often serve data in one of two formats: XML or JSON. In case you decide to make an API for your application, remember that JSON is much more concise and easier to read than XML, and services that provide access to data in XML format are gradually abandoning the latter.

API in web applications with examples

An application - for example, Github - has its own API that other developers can use. How they will use it depends on the capabilities that the API provides and on how well the developers’ imagination works. The GitHub API allows, for example, to obtain information about the user, his avatar, readers, repositories and many other useful and interesting information.

In a similar way, you can send a request in any language, including Ruby. The response to the request will be approximately the following information:

( "login" : "Freika" , "id" : 3738638, "avatar_url" : "https://avatars.githubusercontent.com/u/3738638?v=3", "gravatar_id" : "" , "url" : "https://api.github.com/users/Freika", "html_url" : "https://github.com/Freika" , "followers_url" : "https://api.github.com/users/Freika/followers", "following_url" : "https://api.github.com/users/Freika/following(/other_user)", "gists_url" : "https://api.github.com/users/Freika/gists(/gist_id)", "starred_url" : "https://api.github.com/users/Freika/starred(/owner)(/repo)", "subscriptions_url" : "https://api.github.com/users/Freika/subscriptions", "organizations_url" : "https://api.github.com/users/Freika/orgs", "repos_url" : "https://api.github.com/users/Freika/repos", "events_url" : "https://api.github.com/users/Freika/events(/privacy)", "received_events_url" : "https://api.github.com/users/Freika/received_events", "type" : "User" , "site_admin" : false , "name" : "Evgeniy" , "company" : "" , "blog" : "http://frey.su/" , "location" : " Barnaul" , "email" : "" , "hireable" : true , "bio" : null, "public_repos" : 39, "public_gists" : 13, "followers" : 15, "following" : 21, "created_at" : "2013-03-01T13:48:52Z" , "updated_at" : "2014-12-15T13:55:03Z" )

As can be seen from the block above, the response contains the login, avatar, link to the profile on the site and in the API, user status, number of public repositories and other useful and interesting information.

API alone is not enough

Creating a full-fledged API for your application is only half the battle. How are you supposed to access the API? How will your users access it?

The first thing that comes to mind is the usual series of HTTP requests in order to receive necessary information, and this is the wrong answer. The most obvious method in this case is not the most convenient and simple. It would be much more reasonable to create a special library for working with the interface, which will describe all the necessary ways to receive and send information using the API.

Let’s use Github once again to give an example: to work with the API of this excellent service (and its interface provides extensive capabilities), several libraries have been created in various languages, for example the Octokit gem. In the documentation for such libraries (and the gem given as an example), any interested developer will be able to find all the necessary ways to receive information from Github and send it back through the service API.

Thus, if you are creating your own API, consider perhaps creating libraries to work with it in the most common languages. And be prepared that at a certain level of demand for your application, someone else may create their own library to work with your API. This is fine.

Useful links

In subsequent articles we will talk about how to correctly create an API, ensure its security and limit access to some information.

You've probably seen the term "API". Operating system, web browser, and application updates frequently announce new APIs for developers. But what is an API?

Application Programming Interface

The term API is an acronym and it stands for Application Programming Interface.

An API is like a menu in a restaurant. The menu contains a list of dishes that you can order, as well as a description of each dish. When you specify which menu items you want, the restaurant kitchen does the job and provides you with the finished dishes. You don't know exactly how the restaurant prepares this food, and you don't need to.

Likewise, the API provides many operations that developers can use, as well as a description of what they do. The developer does not need to know how, for example, the operating system is created and the Save As dialog box is displayed. They just need to know that it is available for use in the application.

This isn't a perfect metaphor as developers may have to provide their own API data to get results, so perhaps it's more like a fancy restaurant where you can provide some of your own ingredients for the kitchen to work with.

APIs allow developers to save time by leveraging platform implementation to get important work done. This helps reduce the amount of code to develop and also helps create consistency between applications on the same platform. APIs can control access to hardware and software resources.

APIs make life easier for developers

Let's say you want to develop an iPhone application. Apple's iOS operating system provides a large number of APIs, just like any other operating system, to make this easier for you.

For example, if you want to embed a web browser to display one or more web pages, you don't have to program your own web browser from scratch just for your application. You
You can use the WKWebView API to embed a WebKit (Safari) web browser into your application.

If you want to take photos or videos from iPhone cameras You don't need to write your own camera interface. You can use the Camera API to embed the iPhone camera into your app. If the API didn't exist, app developers would have to create their own camera software and interpret the inputs hardware cameras. But the developers of the operating room Apple systems has done all this hard work so developers can simply use the camera API to embed the camera and then continue writing their application. And when Apple improves the camera API, all apps that use it will automatically take advantage of that improvement.

This applies to all platforms. For example, do you want to create a dialog box in Windows? There is an API for this. Want to support fingerprint authentication on Android? There's an API for this, so you don't have to test every fingerprint sensor from every Android manufacturer. Developers don't have to reinvent the wheel over and over again.

APIs control access to resources

APIs are also used to control access to hardware devices and functions software, which the application may not have permission to use. This is why APIs often play a big role in security.

For example, if you have ever visited a website and seen a message in your browser that the website is asking for your exact location, that website is attempting to use the geolocation API in your web browser. Web browsers provide APIs to make it easy for web developers to access your location - they can simply ask "where are you?" and the browser will do the hard work of accessing your GPS or nearby Wi-Fi networks to find your physical location.

However, browsers also provide this information through APIs because access to it can be controlled. When a website wants to access your exact location, the only way to get it is through the location API. And, when a website tries to use it, you—the user—can allow or deny the request. Hardware resources such as a GPS sensor can only be accessed through an API, so the browser can control access to the hardware and limit what apps can do.

The same principle is used for modern mobile phones. operating systems, such as iOS and Android, where mobile applications have permissions that can be enforced by controlling access to the API. For example, if a developer tries to access the camera through the camera API, you can deny the permission request and the app will not have access to your device's camera.

File systems that use permissions, like Windows, Mac and Linux, have those permissions that are enforced by the API file system. A typical application does not have direct access to a raw physical hard drive. Instead, the application must access the files through the API.

APIs are used for communication between services

APIs are also used for other reasons. For example, if you have ever seen a Google Maps object embedded in a website, that website uses the Google Maps API to embed that map. Google provides APIs like these for web developers, who can then use the APIs to assemble complex objects directly on their website. If no such APIs exist, developers may have to create their own maps and provide their own map data in order to host a small interactive map on a website.

And because it's an API, Google can control access to Google Maps on third-party websites, ensuring that they use it in a consistent manner rather than trying to randomly implement a frame that the website shows Google Maps, For example.

This applies to many different online services. There are APIs for requesting a translation of text from Google Translate or displaying Facebook comments or tweets from Twitter on a website.

The OAuth standard also defines a number of APIs that allow you to log into a site through another service, such as using your Facebook, Google, or Twitter accounts to log into a new website without creating a new one. account user only for this site. APIs are standard contracts that define how developers interact with a service and the type of output that developers should expect to receive.

If you have read this article, you will have a better idea of ​​what an API is. Ultimately, you don't need to know what an API is unless you're a developer. But, if you see that a software platform or service has added new APIs for different hardware or services, it should be easier for developers to use such features.

It should also be noted that the programmer often has several different APIs at his disposal to achieve the same result. Moreover, 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. All you need to do is create an HTML document with a minimal title and a simple body containing this line. What happens when the browser opens this document? The browser program will pass the file name (or an already open file descriptor) to the library that processes HTML documents, which, in turn, using the operating system API, will read this file and understand its structure, calling operations like “clear the window”, “write Hello, world in the selected font!”, during these operations the library of graphic primitives will contact the window interface library with the corresponding requests, and this library will contact the operating system API with requests like “put it in my video card buffer this."

Moreover, at almost each level there are actually several possible alternative APIs. For example: we could write the source document not in HTML, but in LaTeX, and we could use any browser for display. Different browsers generally use different HTML libraries, and furthermore, the whole thing can (generally speaking) be compiled using different primitive libraries and on different operating systems.

The main challenges of existing multi-level API systems are therefore:

• Difficulty in porting program code from one API system to another (for example, when changing the OS);
• Loss of functionality when moving from a lower level to a higher one. Roughly speaking, each API “layer” is created to facilitate the execution of some standard set operations. But at the same time, it becomes really difficult or becomes fundamentally impossible to perform some other operations that are provided by more low level API.

Basic API types

• API access is limited to internal developers only
• Applications are aimed at enterprise employees

Business Drivers:

• Development consistency
• Cost reduction
• Increased development efficiency

Partner APIs

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

Business Drivers:

• Automation of the development process
• Development of partnerships
• Optimizing the process of interaction with partners

Public APIs

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

Business Drivers:

• Development of new services
• Ecosystem Development
• Omnichannel interaction

Most famous APIs

Operating systems API

GUI API

• Direct3D (part of DirectX)
• DirectDraw (part of DirectX)

Audio APIs

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

Authentication systems API

Principle and use of API Economy

• API work must have measurable value. Don't waste resources creating an API that no developer will use.
• Only create an API if it will have a specific user. There must be a partner or ecosystem that needs it.
• The average enterprise always uses more APIs than it creates itself. His departments will deal with a lot of APIs, and the CIO will be tasked with managing this.
• APIs are critical to the Internet of Things, consumer experiences, analytics and information systems. If you forget about these things when creating an API, think carefully.

APIs enable organizations to create personalized user experiences

Customer expectations and behavior are changing

Buyers:

• Require an individualized approach – on their terms
• Expect comprehensive integrated service
• They will switch to anyone who better satisfies their requirements

Organizations:

• Interact with customers through interactive websites, mobile applications created for this purpose and other friendly digital interfaces
• Expect a comprehensive integrated service
• They will move on to anyone who better satisfies their requirements.

APIs are everywhere!

Chronology of events

2019

Research by TAdviser jointly with PJSC VTB Bank with the participation of Skolkovo: API transformation begins in the Russian banking sector

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

On August 21, 2019, it became known that the Bank of Russia acted as coordinator of a pilot project in the field of open APIs (application program interfaces) for the integration of bank services within the Eurasian Economic Union (EAEU). At the time of publication of the material, the Central Bank, together with the central banks of the EAEU countries, is working to prepare the pilot for implementation. Bankers who received the Central Bank’s offer told Kommersant about this. In total, about 20 credit institutions received the regulator’s letter, which must respond about their readiness to participate by August 23. Read more.

The securities industry is ready for APIs

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

The securities industry is nearing a turning point in the adoption of application programming interfaces (APIs) as firms seek greater efficiencies and 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 is driving pilot schemes and use cases, particularly between asset managers and their custodians.

APIs have the potential to help the securities industry cope with multiple and diverse asset types, complex information exchanges, and increasing fee pressures. The report identifies four areas where APIs can benefit the entire industry:

• Efficiency and cost savings through automated data exchange
• Access to real-time information such as settlement status and intraday risk
• Additional services: enriched data and analytics
• Operational metrics allowing service providers to compare performance among market players

API adoption has been slower in the securities industry than in other financial services industries due in part to a lack of regulatory framework and lack of consistency in the willingness of market players to adopt APIs. Asset management companies vary significantly in their technical sophistication and openness to interacting with providers via APIs. About 56% of respondents to the BCG survey consider the level of API adoption in post-trade to be “experimental,” while just 21% say it is “high” or “medium.”

APIs can be a powerful driver of innovation in post-trading, as they have been in the payments industry and other areas of banking. Interest in this technology is growing, and the first experimental results look promising. But to truly drive and accelerate widespread adoption of APIs, we need to remove uncertainty around standards and improve understanding of technology maturity. noted Juliet Kennel, head of the securities and foreign exchange markets department at SWIFT

The report provides four reasons why the industry should implement APIs:

• Interaction within a common infrastructure. Fundamental elements of API solutions such as identity, authentication, security and governance network connections, should be agreed upon at the industry level and not between individual firms.
• Coordinate API standards to maintain interoperability. The proliferation of multiple standards can reduce the effectiveness of using APIs. The industry needs a single API standard that will work across all providers.
• Support for network APIs, not p2p solutions. Firms can benefit from network APIs: for example, a single call to check settlement status from a broker-dealer can be sent to multiple custodians simultaneously. The network solution will support convergence for both data explanation and other API characteristics.
• Meets strict safety and sustainability standards. For successful development, any API solution must have a high level of data protection and sustainability.

API has become one of the key technologies in the digital transformation of the entire banking sector. APIs are now making inroads into the securities industry and becoming a leading technology among companies looking to move to digital servicing. 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. said Sumitra Karthikeyan, head of securities services at BCG

The introduction of an API in the securities market based on SWIFT can ensure the achievement of such key goals as reducing costs and creating additional business opportunities for market participants and, especially, for management companies and end investors. Therefore, NSD is studying the use of open APIs and actively cooperates with SWIFT in matters of standardization of API technology and the practical use of this technology in global post-trading, open banking platform Tink claim that See also

Working with APIs can be both rewarding and frustrating. On the one hand, by interacting with other applications, you can greatly increase the audience reach and “wow” effect of your application. On the other hand, this involves reading tons of documentation, studying authentication strategies, and parsing uninformative (or even missing) error messages.

First of all, if you still don't fully understand what an API (Application Programming Interface) is, read Skillcrush's explanation and then the first part of this article to catch up.

"API" is an incredibly broad concept - every time your application "talks" to another application, it does so through some kind of API. Components within your own application, like different parts of Rails, also talk to each other through APIs. They are more or less independent sub-applications that provide the data each of them needs to perform their own specific tasks. In the app world, everything is an API!

When you create applications with more dynamic front-end functionality (both single-page Javascript applications and simple applications with separate AJAX calls), they will communicate with the Rails backend through your own API, which is really just an extra line or two of code telling your controllers how to serve JSON or XML instead of HTML.

In this tutorial you will learn how to create your own API. In subsequent lessons we will cover how to interact with the APIs of other applications. The lessons should be a good springboard for learning about this topic, but are unlikely to fully cover all cases. A big part of working with APIs is knowing how to read their documentation and figure out what they want from you.

Points to Consider

Review the questions and see if you know the answers. Test yourself again after completing the task.

• How Rails understands what type of file you are expecting in response when you send an HTTP request.
• What is the purpose of the #respond_to method?
• How do you return a User object while specifying the attributes you don't want included in that object (that is, you can't just return User.first)?
• Name the 2 steps behind the scenes of the #to_json method.
• How do you tell a controller action to only render an error message?
• How to create your own error message?
• Why can't you use session-based controller authentication methods if you want to allow programmatic connections to your API?
• What is "Service Oriented Architecture"?

API Basics

Your Rails application is actually already an API, although you might not think of it as an API. The web browser your users launch is also a program, so it actually sends an API request to your Rails application when the user opens new page. We tend to think this way because rendering HTML templates is such a common task that we simply bake this functionality into our server programs as a standard response type, and consider everything else to be something unusual.

However, often you want to make a request that doesn't require you to go through all the headaches of using a browser. You may not care about the page structure (HTML), but in return you want clean data. Let's say you want to get a list of all users. You can request something like http://yourapplication.com/users , which will surely trigger the #index action and render a list of all the app's users.

But why bother with all this extra information if all you want is a list of users? The simplest option would be to send a request to the same URL and expect a JSON or XML response in return. If you configure your Rails controller correctly, you will get back a simple JSON array object containing all the users. Wonderful!

The same principle applies when you communicate with an external API. Let's say you want to get a user's recent tweets from Twitter. All you need to do is tell your Rails application how to interact with Twitter's API (i.e., authenticate itself), send the request, and process the set of "tweets" that will be returned.

Creating an API

You might want to make your Rails application a pure backend API for frontend web pages, or you might just want to learn how to send JSON when the frontend requests it. This section will not cover how to create full-fledged RESTful APIs with authentication functions. This is a smooth introduction to treating your application as an API.

Basics

If you want your Rails application to return JSON instead of HTML, you will need to tell your controller to do so. The great thing is that the same controller action can return different types depending on whether your user is making a regular request from the browser or accessing the API via the command line. This determines what type of request was made based on the extension of the requested file, such as example.xml or example.json .

You can check what Rails thinks about the file type you expect by checking the server log:

Started GET "/posts/new" for 127.0.0.1 at 2013-12-02 15:21:08 -0800 Processing by PostsController#new as HTML

The first line tells you what URL was requested, and the second tells you where it was sent and how Rails processes it. If you were to use the .json extension it would look like this:

Started GET "/posts.json" for 127.0.0.1 at 2013-12-04 12:02:01 -0800 Processing by PostsController#index as JSON

If you have a test application running, try requesting different URLs. If your controller can't handle them, you may get an error, but you should still be able to see what Rails understands your requests to be.

Rendering JSON or XML

Once you decide that you want to respond to requests using JSON or XML, you will need to tell your controller to render JSON or XML instead of HTML. One way to do this is to use the #respond_to method:

Class UsersController< ApplicationController def index @users = User.all respond_to do |format| format.html # index.html.erb format.xml { render xml: @users } format.json { render json: @users } end end end

In this case, #respond_to passes a format object to the block, to which you can attach a corresponding render call. If you do nothing, the html will be rendered using the standard Rails template (in this example app/views/index.html.erb).

The #render function is smart enough to understand how to render a wide range of formats. When you pass it the key:json , it will call #to_json on the value, in this example @users . This will convert your Ruby object(s) into JSON strings that will be passed to the requesting application.

This way you get your API. Of course, creating an API can be a little more complex if you want to do some fancy things, but it all sticks to the basics.

Specifying Returned Attributes

Let's say you want to make sure you don't return the user's email address along with the User object. In this case, you will want to change the attributes that will be returned, modifying what the #to_json method does.

Previously, you would have simply overridden the #to_json method with your version, but now you won't need to - in fact, you will instead override the #as_json method. The #as_json method is used in the #to_json method, so its modification implicitly changes the result of #to_json , but in a rather specific way.

#to_json does 2 things: it runs #as_json and gets a hash of the attributes that will be rendered into JSON. It then renders to JSON using ActiveSupport::json.encode . So by modifying #as_json you are being more specific about the part of the #to_json method that you actually want to change.

In our case, we do this by modifying #as_json in our model to return only the attributes we need:

# app/models/user.rb class User< ActiveRecord::Base # Вариант 1: Полное переопределение метода #as_json def as_json(options={}) { :name =>self.name ) # DO NOT include the email end field # Option 2: Use standard method#as_json def as_json(options=()) super(only: [:name]) end end

Then, our controller will just need to render the JSON as usual (the example below will always return JSON, regardless of whether an HTML request was sent or not):

# app/controllers/users_controller.rb class UsersController< ApplicationController def index render json: User.all end end

Note that you don't need to call #to_json yourself when you use #render - it will do this for you.

Sometimes Heroku may require additional steps to correctly display your pages with errors. Take a look. You may need to remove static pages from the app/public directory first.

Ensuring security from outside

Let's say you want to allow access to the API only if the user is logged in. Your existing authentication in the controller already does this job - just make sure you have the correct #before_action set (e.g. before_action:require_login). You may need functionality where both logged-in and non-logged-in users can view the page, but each should see different data. You don't want unauthenticated users to be able to make API calls to get sensitive data. Likewise, you don't want to allow unauthorized users to visit certain HTML pages.

If you want to handle requests from an application that is not a browser (for example, from command line), you cannot rely on browser cookies for authentication. This is why most APIs use native tokens as part of the authentication process. We'll talk a little more about tokens in the next lesson.

Next steps

You now have the skills to use your Rails application to render not only HTML, but any other format as well. If you want to go further and allow other developers to build things using your platform (for example, so they can make programmatic requests instead of authenticating as a user), you will need to make your API system much more robust. We won't cover it all here, but check out the following:

• The article Building Awesome Rails APIs describes many of the best approaches for moving from a toy application towards industrial API standards.

Service-oriented architecture

It's time to introduce an architectural approach called Service-Oriented Architecture (SOA). The basic idea is that your application will consist of many services, such as a payment system, user registration, recommendation module, etc. Instead of building it all inside one main application, you break the subsystems into completely independent pieces that communicate with each other using internal APIs.

This is good for many reasons. Because each piece of your application doesn't care about how other parts work and only knows how to request data through their API, you can make significant changes to the service code and the rest of the application will work as before. You can completely replace one service with another, and as long as it communicates using the same API methods, it will go very smoothly. You can use external APIs as part of your application (eg payment systems) instead of writing your own. You can create a PHP application that communicates with a Python application that communicates with a Rails application, and everything will work because they communicate with each other using an API.

It's generally a good idea to try to make each part of your application as independent as possible. The concept of SOA forces you to think in terms of what methods you want to expose to other parts of your application, which will also make your code better. In addition, by assuming that each major component of your application is independent, you will also be able to isolate problems much more easily and handle errors in a more meaningful way.

Using a service-oriented architecture for an entire application is like breaking up a giant, complex Ruby script into neat classes and methods, only on a larger scale.

One of the most famous cases of transition to service-oriented architecture is Amazon.com. One day in 2002, Jeff Bezos bluntly stated that all workgroups must move to SOA or be fired. Notorious blog post Google employee, intended for internal purposes but accidentally made public, talked about the power of Amazon using SOA. It's a great read, so be sure to check it out, but the main points of Bezos' letter are summarized in the following quotes from the post:

1) All teams now provide their data and functionality through service interfaces.

2) Teams must communicate with each other through these interfaces.

3) Other forms of interprocess communication are prohibited: no direct links, no direct reading of another command's data, no shared memory models, no backdoors, etc. The only allowed way of interaction is to access the service interface over the network.

4) It doesn't matter what technology they use. HTTP, Corba, Pubsub, proprietary protocols - no difference. Bezos doesn't care.

5) All service interfaces, without exception, must be initially designed with the ability to be controlled externally. That is, the team must plan and design to be able to provide the interface to developers outside the company. No exceptions.

6) Anyone who ignores these requirements will be fired.

SOA is serious business. Sure, there are a lot of problems that come up when using it - check out this post about Amazon's "lessons learned" - but it has an incredible amount of benefits.

You probably won't worry too much about SOA while you're building toy apps for yourself, but it's definitely an issue that will come up when you start working for an IT company, so familiarizing yourself with it is a good practice.

Your goal

1. Read Section 7 of the Rails Controllers Guide to learn JSON and XML rendering.
2. They're not required viewing (because they go a little further than we're currently prepared for), but if you're interested, take a look at Railscasts in the Additional Resources section at the bottom of the lesson to learn more about the benefits of the API.

Conclusion

We'll work more closely with your application as an API during the Javascript course. In this course, you'll create several full-stack applications that use AJAX calls for a better user experience, which essentially involves rendering XML or JSON data instead of a full HTML page. You'll then create several single-page Javascript applications that rely on the API provided by your Rails application to fetch all the necessary data from the database, but otherwise run on the client side (in the browser).

The best way to understand an API is to create and interact with it, which is what we will focus on in our projects.

Advantages:

Types

• returning. Upon request third party application of any method with specified parameters, the server provides the requested information in a certain format;
• changing. The client calls some server function that enters new information or changes certain settings on it.

Yandex.Direct API

API is effective for website promotion.

1. Based on it, developers can create applications that directly interact with the service search engine. Such programs will allow advertisers to flexibly manage large-scale advertising, receive statistical reports on each of them, and accurately forecast budgets.
2. Using the Direct API, advertising agencies can view the entire list of their clients, and clients can view their representatives.
3. If certain phrases used for search engine optimization give a low CTR in contextual advertising, display for them can be automatically disabled. On thematic platforms, you can set rates via the API; certain donors can be removed.
4. The Yandex.Direct API has a SOAP interface, that is, it provides a wide selection of programming languages ​​for creating applications. This protocol is supported by languages ​​such as Perl, Java, Python, etc. Data exchange can also be carried out in JSON format.