"No tricks": A little thought on the topic of API
It all started in 1770 in the Habsburg Empire, when Wolfgang von Kempelen built a machine capable of playing chess. With it, he planned to defeat the best players. Kempelen and his staff quickly became famous, defeating many players during demonstrations and tours of Europe. Among the spectators were even listed Napoleon Bonaparte and Benjamin Franklin.
/ Flickr / Faris Algosaibi / CC
However, this car, which looked like a Turk doll, actually turned out to be a clever illusion. Hand "Turk" managed by a man sitting in the table. All this was just a cheap trick - the secret of the apparatus was discovered only in 1850. From then until the moment when humanity managed to create a machine that won the world chess champion, more than two centuries passed. In 1996, IBM's Deep Blue computer won the match against Garry Kasparov.
')
Source: ProgrammableWeb
Four years after that - in 2000 - Roy Fielding published his work on the topic “Architectural Styles and Design of Network Software Architectures”, which later will form the basis of the architectural style of the REST API.
In the same year, Salesforce released the first version of its API to automate sales. It was followed by the eBay platform, and then other Internet companies. Market participants soon realized the benefits that application programming interfaces can provide. The number of APIs began to grow.
When one of the services makes its interface available to the public, then the person writes documentation for him and shares it. Then another person finds this documentation and, using the experience gained, writes a program that can handle this interface. It turns out that people act as intermediaries for M2M communication. All this very much resembles a trick with a Turkish chess player.
Today, when working with APIs, engineers face difficulties in the following aspects:
Today, API documentation is written and distributed before the two machines “meet” with each other. Even if you ignore the fact that people may misunderstand what is written, there is a problem with changing the documentation. Reconciling API documentation is quite difficult, and maintaining and updating a client is even more difficult.
REST plays a big role in web API success and fits in perfectly with the basics of web operation. Since most APIs do not follow the principles of REST, API clients are often tied to the interfaces used. This creates an extremely fragile system.
Moreover, in order to update an existing client in the event of an API change, it is necessary to spend time and money, and the process itself is rather slow. For this reason, APIs do not evolve. Instead, based on them, new APIs are built, “polluting” the code base.
Today, more and more companies are creating APIs for each task that may interest the user. Many companies start with a single API, but then always come to more individual solutions.
To create new APIs, you have to hire more and more programmers. This leads to an increase in the complexity of system support. However, it doesn't matter how many people we hire, when it comes to writing and reading documentation or adapting existing projects to changes in the API - this part of the work doesn’t scale well. Plus, there is always room for misunderstanding and a different interpretation of formulations - the language is capable of giving too much space for maneuvers.
And finally, it should be noted the problem with the search API. How do we know that there is a service that we would like to use? Perhaps there is already a project that would save time when creating your own solution. It does not matter that there is another geolocation service on the market, it is quite difficult to learn about its existence. You have to rely on word of mouth and search engines.
“To create a fully autonomous API, you need to develop and distribute subject dictionaries that the search system will associate with the API,” says Zdenek Nemec, founder of consulting company Good API.
Autonomous system operation may look like this:
For example, you no longer have to develop a weather application for a particular service. Instead, you create a client that knows how to display a weather forecast, and will “communicate” with AccuWeather, Weather Underground, and other weather applications that use the same dictionaries.
“And the building blocks for creating such a system are already beginning to appear,” notes Zdeněk. “For example, HATEOAS controllers are distributed using one of the hypermedia formats, while adapting the JSON-LD format is already gaining popularity in the API industry, and search providers Google, Microsoft, Yahoo, and Yandex maintain the Schema.org dictionary. Finally, API directories, such as the HitchHQ and Rapid API , are starting to emerge. ”
Perhaps in the future, the API will allow to exclude the human factor in the issues of documentation and search, and we will start programming API-clients declaratively, using dictionaries and other open information. This will make it possible to begin the development of connected devices, unmanned vehicles and progressive medical technologies.
Other materials from the IT-GRAD virtual infrastructure provider blog:
/ Flickr / Faris Algosaibi / CC
However, this car, which looked like a Turk doll, actually turned out to be a clever illusion. Hand "Turk" managed by a man sitting in the table. All this was just a cheap trick - the secret of the apparatus was discovered only in 1850. From then until the moment when humanity managed to create a machine that won the world chess champion, more than two centuries passed. In 1996, IBM's Deep Blue computer won the match against Garry Kasparov.
')
Source: ProgrammableWeb
Four years after that - in 2000 - Roy Fielding published his work on the topic “Architectural Styles and Design of Network Software Architectures”, which later will form the basis of the architectural style of the REST API.
In the same year, Salesforce released the first version of its API to automate sales. It was followed by the eBay platform, and then other Internet companies. Market participants soon realized the benefits that application programming interfaces can provide. The number of APIs began to grow.
New "automatic" cars
When one of the services makes its interface available to the public, then the person writes documentation for him and shares it. Then another person finds this documentation and, using the experience gained, writes a program that can handle this interface. It turns out that people act as intermediaries for M2M communication. All this very much resembles a trick with a Turkish chess player.
Today, when working with APIs, engineers face difficulties in the following aspects:
- Synchronicity
- Version control
- Scaling
- Search
Synchronicity
Today, API documentation is written and distributed before the two machines “meet” with each other. Even if you ignore the fact that people may misunderstand what is written, there is a problem with changing the documentation. Reconciling API documentation is quite difficult, and maintaining and updating a client is even more difficult.
Version control
REST plays a big role in web API success and fits in perfectly with the basics of web operation. Since most APIs do not follow the principles of REST, API clients are often tied to the interfaces used. This creates an extremely fragile system.
Moreover, in order to update an existing client in the event of an API change, it is necessary to spend time and money, and the process itself is rather slow. For this reason, APIs do not evolve. Instead, based on them, new APIs are built, “polluting” the code base.
Scaling
Today, more and more companies are creating APIs for each task that may interest the user. Many companies start with a single API, but then always come to more individual solutions.
To create new APIs, you have to hire more and more programmers. This leads to an increase in the complexity of system support. However, it doesn't matter how many people we hire, when it comes to writing and reading documentation or adapting existing projects to changes in the API - this part of the work doesn’t scale well. Plus, there is always room for misunderstanding and a different interpretation of formulations - the language is capable of giving too much space for maneuvers.
Search
And finally, it should be noted the problem with the search API. How do we know that there is a service that we would like to use? Perhaps there is already a project that would save time when creating your own solution. It does not matter that there is another geolocation service on the market, it is quite difficult to learn about its existence. You have to rely on word of mouth and search engines.
Possible Solution
“To create a fully autonomous API, you need to develop and distribute subject dictionaries that the search system will associate with the API,” says Zdenek Nemec, founder of consulting company Good API.
Autonomous system operation may look like this:
- The machine publishes its interface along with the profile that describes it and the vocabulary of the subject area. She then registers herself in the API search service.
- Then another machine polls the search service using terms from dictionaries. If the APIs that use them are found, the search service reports the existence of the desired service.
- Now the client can use the API for his needs (it is believed that he has already been “trained” to work with the requested dictionary).
For example, you no longer have to develop a weather application for a particular service. Instead, you create a client that knows how to display a weather forecast, and will “communicate” with AccuWeather, Weather Underground, and other weather applications that use the same dictionaries.
“And the building blocks for creating such a system are already beginning to appear,” notes Zdeněk. “For example, HATEOAS controllers are distributed using one of the hypermedia formats, while adapting the JSON-LD format is already gaining popularity in the API industry, and search providers Google, Microsoft, Yahoo, and Yandex maintain the Schema.org dictionary. Finally, API directories, such as the HitchHQ and Rapid API , are starting to emerge. ”
Perhaps in the future, the API will allow to exclude the human factor in the issues of documentation and search, and we will start programming API-clients declaratively, using dictionaries and other open information. This will make it possible to begin the development of connected devices, unmanned vehicles and progressive medical technologies.
Other materials from the IT-GRAD virtual infrastructure provider blog:
Source: https://habr.com/ru/post/316292/
All Articles