CRUD — HTTP API

• Adding a user
• Updating a user
• Deleting a user
• Idempotency

In programming, the abbreviation CRUD stands for four basic operations that you can perform on information: creating, reading, updating, and deleting.

CRUD operations work around an entity, such as a user. To operate, they create an interface using forms or HTTP API endpoints.

The Dummy JSON service provides a complete set of these operations for entities. Let's take a closer look at them.

This service doesn't perform actual changes on the server for security reasons. All the operations look like they make changes, but the changes don't happen

Let's consider that example:

Here you see 1. It is the identifier for a particular user. It will change depending on which user we're working with right now. By the way, the identifier doesn't have to be a number. It depends on what the backend considers an identifier and how we create it in the database. For example, in MongoDB, the identifier consists of numbers and letters.

Note the use of HTTP methods:

• GET is for fetching data
• POST is for forms creating
• PATCH is for updating
• DELETE is for deleting

The URL, however, often remains the same.

Using the correct methods is handy when it comes to working with APIs. Any HTTP requests around the Internet are handled by web servers and intermediate proxies on the way to the server. Both the web server and proxies are aware of the different features of HTTP and can perform various optimizations depending on request parameters, like caching the result.

Caching is a technique that allows a web server or proxy to save a response from a server and return it for future requests without contacting the server itself. Caching speeds up access to resources and takes the load off servers. For example, we can cache GET to speed up access because GET never changes the data, i.e., it's safe. The POST, PATCH, and DELETE methods cannot be cached. They have to come to the server because they make changes.

Adding a user

According to the documentation, we can add a user by sending a POST request to the endpoint https://dummyjson.com/users/add. We can send data in different formats, such as HTML or JSON.

To use JSON, you need to perform two steps while preparing a query:

• Enter a Content-Type header with the value application/json
• Convert the data to JSON

The result is that the query will look like this:

POST /users/add HTTP/1.1
HOST: dummyjson.com
Content-Type: application/json

{ "firstName": "Nik", age: 20 }

What are the possible responses from the server:

• 201 — resource successfully created
• 422 — validation error
• 406 — incorrect data or wrong format

Read more about HTTP codes here. Most of them can occur with any HTTP method.

Updating a user

To update the user, we must send a PATCH request to the endpoint https://dummyjson.com/users/{id}. You can update any set of parameters, not necessarily all at once:

PATCH /users/1 HTTP/1.1
HOST: dummyjson.com
Content-Type: application/json

{ "firstName": "Nina" }

If everything goes well, there are two possible responses:

• Code 200 and some data, such as JSON with updated resource data
• Code 204, if there's no response body

Deleting a user

To delete a user, we must send a DELETE request to the endpoint https://dummyjson.com/users/{id}. There is no request body in this case because everything is clear from the request address:

DELETE /users/1 HTTP/1.1
HOST: dummyjson.com

If everything goes well, there are two possible responses:

• Code 200 and some data
• Code 204 and an empty response body

Idempotency

When working with APIs, request idempotency is crucial. It is a property that tells you how safe it is to repeat an HTTP call. An idempotent query gives the same result regardless of the number of calls made.

Take the /users endpoint. It returns a list of users and does not change anything on the server. Each new call to this endpoint returns an identical list of users. Therefore, it's idempotent. The user list may change if it's changed somewhere else, but even that doesn't make a GET request to /users not idempotent. The main thing is that the query itself does not change anything.

The POST request, on the other hand, is not idempotent. Each call to /users/add adds a new user, albeit with the same data. Or it returns an error if, for example, the server has added a uniqueness check for some data. That's why when you send a form and refresh the page using F5, the browser always asks if you want to make this request again.

PATCH is conventionally also not idempotent, but it's often made idempotent in practice. But browsers or web servers can no longer rely on this because they don't know the specifics of particular applications.

The most curious thing is that DELETE is idempotent by convention. It means that deleting an already deleted resource again should return a 204 code, according to the HTTP specification. In practice, many programmers don't know about it, so usually, a second deletion leads to a 404 error.

Idempotency is fixed for HTTP methods in its specification, but the extent to which HTTP APIs comply with these rules depends on the programmers.