Register to get access to free programming courses with interactive exercises


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 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

Method URL Operation
GET /users List of users
GET /users/1 User information
POST /users/add Add a user
PATCH /users/1 Update a user
DELETE /users/1 Delete a user

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 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
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*{id}*. You can update any set of parameters, not necessarily all at once.

PATCH /users/1 HTTP/1.1
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{id}. There is no request body in this case, because everything is clear from the request address

DELETE /users/1 HTTP/1.1

If everything goes well, there are two possible responses:

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


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.

Hexlet Experts

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

For full access to the course you need a professional subscription.

A professional subscription will give you full access to all Hexlet courses, projects and lifetime access to the theory of lessons learned. You can cancel your subscription at any time.

Get access
hours of theory

Sign up

Programming courses for beginners and experienced developers. Start training for free

  • 130 courses, 2000+ hours of theory
  • 1000 practical tasks in a browser
  • 360 000 students
By sending this form, you agree to our Personal Policy and Service Conditions

Our graduates work in companies:

<span class="translation_missing" title="translation missing:">Bookmate</span>
<span class="translation_missing" title="translation missing:">Healthsamurai</span>
<span class="translation_missing" title="translation missing:">Dualboot</span>
<span class="translation_missing" title="translation missing:">Abbyy</span>
Suggested learning programs
Development of front-end components for web applications
10 months
from scratch
Start at any time

Use Hexlet to the fullest extent!

  • Ask questions about the lesson
  • Test your knowledge in quizzes
  • Practice in your browser
  • Track your progress

Sign up or sign in

By sending this form, you agree to our Personal Policy and Service Conditions
Toto Image

Ask questions if you want to discuss a theory or an exercise. Hexlet Support Team and experienced community members can help find answers and solve a problem.