CRUD — HTTP API

In programming, the abbreviation CRUD stands for 4 basic operations that you can perform on information: creating, reading, updating, and deleting. CRUDs are built around an entity, such as a user. To do this, either create an interface using forms, or create HTTP API endpoints.

The service https://dummyjson.com in fact provides a full set of these operations for its entities. Let's take a closer look at them.

For security reasons, this service doesn't perform real changes on the server. All the operations look like they make changes, but the changes don't actually happen

1 - 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, here it all depends on what the backend considers an identifier and how it's created in the database. For example, in MongoDB, the identifier consists of numbers and letters.

Note the use of HTTP methods. They have a certain sense and it is used here. GET is for fetching data, POST is for forms (creating), PATCH is for updating and DELETE is for deleting. The URL, however, often remains the same.

Using the right methods is important when it comes to working with APIs. Any HTTP requests that go around the Internet are handled by web servers and intermediate proxies that may be found 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, e.g., 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 having to contact the server itself. Caching significantly speeds up access to resources and takes the load off servers. For example, GET can be cached 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 to add a user, we have to send a POST request to the endpoint https://dummyjson.com/users/add. Data can be sent in different formats, e.g., as data from a regular HTML form or as 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, e.g., 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 it comes to working with APIs, the notion of request idempotency is very important. This 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're sending a form and refreshing the page using F5, the browser always asks if we really want to make this request again.

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

The most interesting thing is DELETE, which, by convention, is idempotent. I.e., deleting an already deleted resource again should, according to the HTTP specification, return a 204 code. In practice, not many programmers 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.

---

Are there any more questions? Ask them in the Discussion section.

The Hexlet support team or other students will answer you.

About Hexlet learning process

• Article “How to Learn and Cope with Negative Thoughts“
• Article “Learning Traps“
• Article “Complex and simple programming tasks“