Rivalry2

HTML Diff

1 added 1 removed

Original 2026-01-01

Modified 2026-02-26

1 <p>С чтением данных мы разобрались, давайте теперь попробуем их записывать. Создание новой записи в нашей телефонной книге через telnet будет таким:</p>

2 <p>Отметим несколько важных моментов:</p>

3 <p>Добавлению новых данных в http соответствует глагол POST. Такой запрос не является идемпотентным (в соответствии с семантикой POST). Это означает, что повторная отправка данных приведёт к созданию дублей либо к ошибке (если внутри проверяются дубли).</p>

4 <p>Почти наверняка вы сталкивались с подобным поведением в интернете. Быстрый двойной клик на кнопке приводит к тому, что появляется, например, два комментария. А иногда, когда вы нажимаете f5, браузер спрашивает "вы точно хотите повторно отправить данные?". Это означает, что предыдущий запрос был POST.</p>

5 <p>Так как в случае POST запроса мы отправляем тело, нам нужно указать два заголовка:</p>

6 <ul><li>Content-Type - чтобы сервер знал, как парсить наше тело</li>

7 <li>Content-Length - для определения конца запроса</li>

8 </ul><h2>Сервер</h2>

9 <p>С точки зрения сервера body не является свойством объекта request, вместо этого сам request является eventEmitter и позволяет подписаться на событие data, которое вызывается каждый раз, когда приходит новая порция данных. Такой подход используется из-за того, что данные можно слать на сервер порциями (chunks).</p>

10 <p>После того, как запрос был полностью обработан, request инициирует событие end, внутри которого и нужно делать обработку поступивших данных и отвечать на запрос.</p>

11 <p>Обратите внимание на то, как идет работа с чанками данных. Перед тем, как попасть в массив body, делается преобразование в строку с помощью toString. Это связано с тем, что сырой чанк приходит как тип данных Buffer, который позволяет работать в том числе с данными в бинарном виде, а не только текстовом.</p>

12 <h2>Валидация</h2>

13 <p>В разработке существует правило: "никогда не доверяй данным из внешнего источника". Это означает, что данные пришедшие извне (от других систем, от пользователя), всегда рассматриваются, как потенциально опасные и не соответствующие требованиям формата этих данных. Если этого не делать, не проверять их, не фильтровать, то легко можно получить ситуацию, при которой вашу систему смогут обойти и, в худшем случае, разрушить или увести данные.</p>

14 - <p>Процесс проверки данных на корректность называется валидацией. В типичных веб-приложениях данные приходят из форм, которые заполняют пользователи или по API, и перед тем, как добавлять их к себе в хранилище, важно<em>провалидировать</em>эти данные. В самой валидации нет ничего сверхъестественного, это обычная проверка в коде, например, на то, что телефон приходит в строго определенном формате.</p>

14 + <p>Про��есс проверки данных на корректность называется валидацией. В типичных веб-приложениях данные приходят из форм, которые заполняют пользователи или по API, и перед тем, как добавлять их к себе в хранилище, важно<em>провалидировать</em>эти данные. В самой валидации нет ничего сверхъестественного, это обычная проверка в коде, например, на то, что телефон приходит в строго определенном формате.</p>

15 <h2>Ответ</h2>

16 <p>Важно отвечать на POST запрос правильно, и это зависит от разных факторов. Выделим три ситуации (хотя, их больше на самом деле):</p>

17 <h3>Успешный запрос (API)</h3>

18 <p>Код ответа 201 (Created). В теле ответа обычно возвращают данные, такие как присвоенный идентификатор, что позволяет обратиться к вновь созданной сущности.</p>

19 <h3>Успешный запрос (Web)</h3>

20 <p>Необходимо обязательно сделать перенаправление (редирект) на другую страницу. Предпочтительно использовать код 303 (See Other).</p>

21 <h3>Ошибка валидации</h3>

22 <p>В этой ситуации код ответа должен быть 422 (unprocessable entity) в любом случае. Для разных видов приложения будет различаться только тело и его формат.</p>