REST 1

API 2
API
API (Application Programming Interface)
API is the abbreviation for Application Programming Interface which refers to a strictly de ned
set of rules and their descriptions, which computer programs use to communicate.

3
API

Flight search engine: search-

ight.com, it does not have its
own database and it cannot use
the databases of airlines
directly.

It establishes an interaction
with the API of particular 4
airlines, searches all their
results to nd the cheapest,
most convenient connection
among all of the available
o ers on the market and it
serves it to the user.
REST 5
REST
REST (Representational State Transfer)
Representational State Transfer is a software architecture style based on a collection of
previously de ned rules which describe how resources are de ned and allowing access to
those resources.

In the case of Web API, it is based on the HTTP protocol.

Such actions within a system as create, read, update, delete (CRUD) are carried out by HTTP: POST, 6

GET, PUT, DELETE.

REST Rules
#1 UNIFORM INTERFACE

The interface allows for standardized communication between the client and the server. 
While designing one API interface we respond to the needs of all applications regardless of what
platform they are prepared for.

7
REST Rules
#2 CLIENT - SERVER

The client application is completely separated from the server application. This way both
applications can be developed independently.

8
REST Rules
#3 Stateless

The REST architecture does not store any information between requests. Each request must include
a complete set of the required information for it to work properly.

9
REST Rules
#4 Cacheable

The client-side should be able to store resources in order to increase e ciency.

10
REST Rules
#5 Layered System

The Client should not be able to tell if it is connected directly to the server or to a proxy. When it
sends a request it should obtain a response without the need to know "what happens on the other
side".

11
REST methods (HTTP)

REST methods are the same as HTTP methods, hence the table below is a reminder of the HTTP
methods.

HTTP Description
Method
GET Downloading the resource and displaying it, e.g. displaying a form or a page.
POST Sending data stored as key-value pairs to the server (e.g. sending a form, where the key 12
is the name of the given eld and the value is the value we assigned).
PUT Update of the given resource
DELETE Removing the resource on the server. For security purposes, this method is practically
always disabled.
REST (HTTP) response code
REST response codes, similarly to methods, are the same as HTTP response codes.

Most common:
• 200 – everything is OK, the request has been served

• 302 – redirect

• 403 > – no access

13

• 404 – not found (therefore the number 404 is often presented on pages with the information that
the provided address does not exist)
• 503 – service unavailable – the server is not able to carry out this request at the moment due to
overload
REST (HTTP) response code
Although there are many di erent codes, most often knowledge of the basic ones is su cient. What
is important is that even if you don't know the code you can get the idea of the meaning, because
codes are divided into groups. The rst digit of the code states which group it belongs to:

• 1xx – informational

• 2xx – successful request

• 3xx – redirection, the request should be sent to a di erent address / server

14

• 4xx – error of the application caused by the user

• 5xx – server error

The exact description of all codes is available on Wikipedia.

 POSTMAN 15
Working with API
POSTMAN - rst steps
At the beginning of our work, we can decide if we will perform individual Requests, or if we want to
gather requests into a Collection.
For the purpose of this course, we create a Collection called VisualityTestAPI.

16
POSTMAN - let's test
For in-course testing, we have selected the Star Wars API available here: https://swapi.dev/. Before
beginning the work with an API and Postman it is important to become familiar with the API
documentation.
Every API should be documented for developers and testers to know what methods they can use.

Exercise
Let's analyze what methods and parameters can be used in the Star Wars API. API is available here:
17
https://swapi.dev/documentation.
POSTMAN - rst request

We select what type of method (request) we want to test.

18

For the purpose of the course, we will test the GET method. The remaining methods often require
proper authorization (API keys) before they can be executed on a server.
POSTMAN - rst request

Let's fetch all data available through the

API. In the Enter request URL eld type in
the main API address and press SEND.

19
Give it a moment. A request for all available data takes a while to process.
POSTMAN - rst request

In order to store our request press SAVE.

Then type in the name for the request and select the collection where you 20

want to store it.

POSTMAN - more requests

The structure of requests can be built in any given

way. In order to create another request click on
the "+" symbol.

21
POSTMAN - request parameters
A list of parameters that we can use in our API is available in the documentation.
Let's type in a request to display all Star Wars movies.

https://swapi.dev/api/ lms

Enter the request into Postman and verify the result.

22
POSTMAN - request parameters

After clicking Send we receive a response in the

form of Status code and the response Time. The
content of the response is delivered as a JSON
le.

23
Exercise

Create a new collection - name: Star Wars.

Familiarize yourself with the API documentation here: https://swapi.dev/documentation.

Add 2 new requests to the collection: 24

• Description of a Star Wars ship with id = 9.

• In the response to the previous request, there is information about the movie in which this ship is
found. Prepare a request which will describe this movie.

Duration: 15 minutes
POSTMAN - initiating all requests

After storing all requests in the given collection we can initiate all
requests in the order in which they are stored.

Summary

25
 THE END 26
Go to the next presentation