REST (Representational State Transfer) was introduced and described by Roy Fielding in his doctoral dissertation in 2000. REST is an architectural style used to design distributed systems.

REST is an architecture that works over the HTTP protocol that provides communication between client-server. REST is a transfer method used in software based on service-oriented architecture. It provides communication between the client and the server by carrying XML and JSON data.

Rest services;

• They are platform-independent. (It doesn’t matter if the client is Windows, and the server is Linux)
• They are language independent.
• They work over HTTP.
• They are flexible and can be extended very easily.

What is RESTful API?

If it’s RESTful; Services that use REST architecture. An adjective used to describe the API if an API has all the limitations of the REST architecture. RESTful services can have many different response types. RESTful services are simple and light, unlike SOAP, RPC. JSON is popularly used these days, but XML, CSV or even HMTL can be used depending on the purpose.

How should RESTful URL Structure be?

We should avoid complex naming and unnecessary parameters over the URL. For example, when we examine the following endpoint;

GET https://api.systemconf.com/users/123

When we make a GET request, we want it to bring the record with 123 ids in “Users”, even if we make a DELETE request at the same endpoint, we delete the user with 123 ids. We should think of the URLs we create on the API as a sentence as much as possible.

Companies Using REST and RESTful

• Twitter has the Rest API of Facebook.
• Google, Amazon, Azure has many REST services that can be used for various purposes.
• Blizzard World of Warcraft, one of the most famous game companies in the world, offers its players information about their characters through RESTful services.

RESTful API or REST API

APIs with the contents below are called RESTful APIs. If even one of the items is not provided, the API loses its “RESTful” feature. We recommend that you know these items in order to distinguish whether an API is a RESTful API or a REST API.

Client and Server: Client deals with front-end, server deals with back-end. Both can be changed independently of each other.

Statelessness: The storage data of the client’s query and session state is not hosted on any server.

Caching: Clients can cache the response to improve performance.

Layered System: The client cannot tell whether it is connected to the trailing server or an agent during the in-between process.

Code on demand: Servers can send, extend, or customize code by temporarily executing the client’s functionality.

Uniform interface

It represents the immutable foundations of the RESTful API. This interface simplifies the architecture and divides it into parts. In this way, each side can develop independently from each other. There are four limitations to the invariant interface. We will continue this article with separate items, but the “unchanging interface” is the basis of a RESTful API. These features are not independent of the list above.

Resource Determination: Resource identification is essential for the RESTful API. Resources are determined by requests. This is usually accomplished using the uniform resource identifier, URI, that does not change in web-based systems. References are not the same as presentations. The server can send the result data from the database as HTML, JSON or XML, although none of them has an internal presentation.

Manipulation of resources through these representations: If any client has a representative source with linked metadata, it has enough information to modify or delete the resource.

Self-explanatory messages: All messages have enough information on how to handle them. For example, it is determined by an internet media type that the parser will run.

Hypermedia as application state engine: Clients can make the status change with dynamic actions determined by the server.

Restful API Standards and Examples

The following items are not mandatory rules. They have accepted patterns that are preferred to follow when developing a Restful API.

When making an API, we should collect the transactions belonging to the same class under a group. For example, when we want to access and perform transactions belonging to users via API, we must do it all over the “Users” URL.

• We must create these endpoints that represent a class or group for a specific purpose, with a plural name. For example;

api.systemconf.com/companies instead of api.systemconf.com/company
api.systemconf.com/users instead of api.systemconf.com/user

• In GET requests that we will assign directly to the endpoint we created, we must return the entire list of that class. For example;

api.systemconf.com/users
api.systemconf.com/companies

• When we want to access a single record belonging to a class, we must send a request to the class to which it belongs, with a unique id value representing it, and return the information of that class in return. For example;

api.systemconf.com/users/1
api.systemconf.com/users/CFAF1A94-91D6-4413-9320-7DD7157A2E54

• When we want to create a new record for a class, we need to send this new information directly to its class along with the POST request in the body. For example;

api.systemconf.com/users

• When we want to delete the record of a class, we must delete it when we send a DELETE request with its id value. For example;

api.systemconf.com/users/5
api.systemconf.com/users/CFAF1A94-91D6-4413-9320-7DD7157A2E54

• In the registration of a class, when you want to access other classes connected to it, that is, when you want to reach the notifications of the User registration under a Users, you can return under an ordered URL similar to the following.

api.systemconf.com/users/2/notifications

Thus, when you look at the URL, you can easily understand what it does.