🏠 | 💻 PC | 🔨 Testing |

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:


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

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

Calculator. Http methods. Protocols/rfc2616.

Share in social media: