API Testing
What is API
In a broad sense, the API
is the method that an application provides to external users to communicate with it.
Usually via the Internet.
It can be interaction with the application server on the smartphone, between computers or other devices.
Another popular term close in meaning to the API is
Web services
APIs are used where it is impossible or undesirable to directly integrate with the source application, i.e. almost everywhere.
Example № 1: If you want to place Yandex maps on your site, you do not need to install programs from Yandex, just send
a few requests and Yandex will pass the necessary information. This is possible because the Yandex programmers have developed
a special set of requests - APIs that can be sent to them on the server in order to get a card in response.
Example № 2: Suppose you created a site vk2.com. You want the webmasters to be able to add to their sites the ability
to comment on entries using the vk2 account, but you do not want to disclose or distribute your code.
To work around this problem, you post in public access the rules by which webmasters can refer to vk2 to get comments.
The format of these messages is either JSON or XML. We will talk about them later.
Again, to reinforce the essence: The point is that a site written in any language that supports HTTP requests does not send
any PHP / C / Python commands to the server, but communicates with it using the requests described in the API.
The address to which the messages are sent is called Endpoint. Usually this is the URL (for example, the name of the site)
and the port. If I want to create a web service on port 8080 Endpoint it will look like this:
http://aredel.com:8080
If my Web service needs to respond to different messages, I will create several URLs (interfaces) at the same time, which can be accessed by the service. for example
http://aredel.com:8080 /resource1/status
http://aredel.com:8080 /resource1/getserviceInfo
http://aredel.com:8080 /resource1/putID
http://aredel.com:8080 /resource1/eventslist
http://aredel.com:8080 /resource2/putID
...
As you can see my Enpoints have different endings. Such an ending in Endpoint are called Resource, and the first part Base URL.
Endpoint = Base URL + Resource
After that, all these interfaces are created, they need to be described. Need a document from which it will be clear
- What methods can be used by sending requests's for each Endpoint
- Should any data be transmitted?
- If you want to transfer data in the request body, specify what exactly
- What kind of responses we expect in case of a successful request
- What kind of responses we expect when something is wrong with the request or its processing on the server
This document should be available to developers on both sides, otherwise they simply
will not be able to negotiate and implement a working Web service..
Let's return to the first point of the list, namely to what are
methods.
There are several ways to send a request to the same HTTP protocol
Endpoint. They're called
CONNECT, DELET, GET, HEAD, OPTIONS, PATCH, POST, PUT, TRACE about their properties you can
read
here.
When we know which methods with which Enpoint can be used to compose queries
it will not be difficult. For example:
GET http://aredel.com:8080 /resource1/status
GET http://aredel.com:8080 /resource1/getserviceInfo
PUT http://aredel.com:8080 /resource1/putID
GET http://aredel.com:8080 /resource1/eventslist
POSThttp://aredel.com:8080 /resource1/eventslist
PUT http://aredel.com:8080 /resource2/putID
...
So, the basic request consists of a method and an Enpoint
Request = Method + Endpoint
Example API
Basic API Example:
I created a program on the site that extracts from the database the number of
cyclists in the city. Interaction with the API will look like this: You send
POST http://aredel.com:8080 /bicylists
Where body of the request will containe the city name
{ "city": "Helsinki" }
And my site will return you the number of cyclists. In this case - in Helsinki