The REST approach is one of the most widespread in the design and development of web APIs. Within the REST architecture, based on HTTP, operations occur through specific "verbs" known as HTTP Methods, which allow interaction with resources.

The 5 most common HTTP Methods in the development of RESTful APIs are GET, PUT, DELETE, POST, and PATCH: these essential "verbs" allow the execution of the so-called CRUD operations (Create, Read, Update, Delete), that is, they allow creating, reading, updating, and deleting resources.

REST APIs: what they are

REST or RESTful APIs are those that follow the principles of Representational State Transfer (REST), an architectural style defined in 2000 by computer scientist Roy Fielding which includes, among other things, the clear separation of client and server, the adoption of uniform interfaces, and the creation of a layered structure in which each level has its specific responsibilities.

When a request is made through a REST API, the API transfers to the client not the actual resource, but a representation of its state, which is sufficient to satisfy the request.

To be considered RESTful, an API must comply with the following principles:

• Stateless client-server communication: each request is separate and no information is stored;

• Possibility to cache data;

• Uniform interface: this means that resources must be identifiable and separate from the representations sent to the client and must be manipulable through that representation;

• Layered system that organizes servers in precise hierarchies (invisible to the client).

Applying these concepts allows the development of fast, lightweight, and easily scalable APIs and today forms the basis of web API development.

The role of HTTP Methods in RESTful APIs

In a RESTful API request, the information (that is, the representation of the resource) can be transferred in various formats, from JSON to HTML. However, communication always takes place through an HTTP request.

HTTP Methods, in particular, are crucial components of every REST API, as they allow the client to specify the action to be performed on the resource and thus interact with it. Also known as HTTP “verbs,” these elements are present in every RESTful API request and allow the client to perform CRUD actions (Create, Read, Update, and Delete) on resources in a standardized and predictable manner.

In a REST API architecture, both idempotent HTTP Methods such as GET and PUT, which enable the development of an efficient web service with high error tolerance, and non-idempotent methods are used. The difference is substantial: by using idempotent methods, multiple calls with the same parameters produce the same effect as a single call, without multiplying the possible effects of the operation on the server and always returning the same information. When non-idempotent “verbs” like POST and PATCH are used instead, the server state can be modified, exposing the system to various side effects, including the creation of unwanted resources.

The 5 fundamental HTTP Methods in RESTful API services

Among the most common HTTP Methods in REST APIs are GET, PUT, DELETE, POST, and PATCH, which allow the client to read a resource, create it, delete it, or modify it:

• GET: is the most common method in API requests. It is used to request a view of the data from the server and is idempotent: repeating the same request several times will return the same representation, without modifying the server state;

• PUT: updates an existing resource by replacing its entire content or creates a new one; it is mainly used to update resources. During creation, in fact, it carries the risk of unintentionally generating resources;

• DELETE: deletes a resource. It can be considered idempotent, but it may leave the URL of the deleted resource available, with possible consequences on the consistency of subsequent responses from the server;

• POST: is the only method that operates mainly on resource collections. It is used to create a subordinate resource with a URL within a collection, associating it with a precise hierarchy. It is not inherently idempotent: each call can potentially generate a new resource;

• PATCH: like PUT, is used to update resources. It works by partially modifying the contents of resources through changes expressed in standard formats like JSON and XML. Repeating the same PATCH request can lead the resource to assume different states, so it cannot be considered idempotent (however, the verb can be used in a way that makes it idempotent).

Only idempotent methods can be considered safe, as they do not affect the server state and allow predicting the effects of client operations on the server and individual resources. However, even non-idempotent methods like POST and PATCH can be used safely by implementing appropriate authentication, authorization, and API request management systems.

Other HTTP Methods for API development

In addition to the five HTTP Methods described, which are linked to CRUD operations, there are others that are very useful in the development of RESTful APIs, as they do not modify the resource state but allow performing important actions such as checking its status or following the path of a request:

• HEAD: is used to query the metadata of resources, for example, to verify their size or status before proceeding with another request;

• OPTIONS: allows obtaining a list of methods supported by the queried resource, and therefore determining which operations can be performed on it;

• TRACE: can be used as a debugging tool, as it allows the client to see how its request is modified by intermediate servers along the path. It does not modify the server state but is a very sensitive method, as it can expose sensitive data. Not surprisingly, there is a type of cyberattack, known as Cross-Site Tracing (XST), which is based exclusively on this HTTP Method.

HTTP Methods are one of the fundamental pillars in the development of RESTful APIs: by defining operations in a standardized and predictable way, they make APIs interoperable and facilitate their integration within applications. Using the standard also makes APIs more intuitive and easier to use even for the client.