What is the API?
First of all let’s outline what an API is. API is an acronym for Application Programming Interface. Similarly to the User Interface where humans require some visual (or for instance audio) representation of information and ways to interact (e.g. button controls, audio input controls), programs also require an interface. Still for programs it is much better to use a programming interface which in simple words is some object that exposes public properties and methods to other objects. Modern programs are able to interact with a User Interface same as humans, but this interface is not always structured in the best manner for the machines and what is more important it is not the best way of interaction in terms of performance, scalability etc.
Why do we need API?
When you drive your car, do you ever think how everything works under the hood? E.g. how does the engine start, how does the brakes stop the car? And do you really need to know this? Well, probably you need to know some basic things about it, but surely not to the extent of each detail and how to mend it if anything gets broken. You have your own important things to do. Basically all you need to drive a car is a key, steering wheel and pedals to accelerate and break. And that is your API. Same about the applications. They might use a really huge module with enormous amounts of code, which does some heavy-weight computations, but only exposes a few properties and methods to your application. That’s what is cool about API and that’s basically what API is and why we need.
Types and levels of API?
There are multiple types of APIs and in many cases the type is very related to the level of the application where it is used. I would outline the following levels of API:
- Internal application API. For instance components of application which talk to each other on the level of its internally exposed properties and methods.
- Modules API. 99% of applications are now using some 3rd party modules, plugins, libraries etc. All of them provide some public API in order to use them.
- Container API. Many apps are running within some other applications. The easiest example is the web app running inside the browser. Yeah, any website (web app) that we run inside the browser (which is basically a container) has a possibility to leverage the container’s API. Browsers have plenty of different APIs that will allow you to make your app better in terms of user experience, performance, flexibility and so forth.
- Operation System API. This level of API is exposed to the apps which were installed using corresponding OS. For instance if you installed the app from Google play market, you are able to leverage usage of Android OS API, e.g. Camera API, File Storage API etc.
- Low level API. OS in its turn is using very low level commands which are exposed directly by the CPU, Network, Hard Drive, Memory etc. By the way, it is not done directly. For instance Windows is using additional middleware so-called drivers for this which many of you might have heard about.
One of the most complex and important types of API nowadays is a Network API. It allows multiple machines to communicate to each other. Without it our world would not be the way it is now. On top of the Network, there have been built multiple protocols and the most popular of them is TCP. Still, TCP protocol is not the most convenient and obvious for coding some integrations between the distributed applications. Therefore, another protocol has been
introduced many years ago, particularly HTTP. 99% of programmers know what it is.
Even though this protocol was invented for the web sites (or client-server applications), the simplicity, trends and popularity of the web, forced other types of applications like desktop and mobile to use HTTP protocol too. Sometimes it is way too simple and primitive, thus many other types or better to say standards of APIs and even new protocols have appeared on top of the HTTP. Below we’ll list most popular:
- SOAP
- RPC
- OData
- REST
- GraphQL
What is an API for tests?
Most of the apps are using a distributed (3rd party) API. During the app development stage, some APIs might not be ready yet. But this should not prevent or block the development of your application. For this purpose there are such services that allow you to create some temporary dummy version of the real API or in other words an dummy API or API for tests. All of the APIs that run over the HTTP protocol share the same properties like URL and method which is basically a name of the method and optionally an input data. We may also call it an endpoint. And each of the endpoints produces a response (divided to headers and body with response code). One of the very interesting services for creating API for tests is QuickMocker. You do not need to have any knowledge about and experience with creating APIs. Same as we talked about driving a car at the beginning of the article. All you need to know is the basics, in our case how HTTP works on a top level (URL, method, request/response headers and body, status code etc). You may set up in a few minutes the dummy endpoints or mock endpoints required by your application or import them within seconds using OpenAPI schema. Except for this you can intercept any request to your dummy or fake API and forward it to your local application in order to test webhooks. It requires a simple one-time set up and no need for some additional software. The only thing you need is a browser.
