Как обработать GET-запрос на несуществующий элемент?

Question

[Сергей Малинин]

Я сделал небольшое rest-api.

На фронте мне нужно реализовать следующую логику:
- Формирую GET-запрос на получение элемента и БД по дате.
- Если элемент не найден, на фронте собираю необходимые данные для создания элемента
- После оплаты пользователем заказа отправляю POST-запрос на создание элемента.

То, что при такой логике можно насоздавать кучу элементов, понимаю. В этом нет проблемы, т.к. запрос на создание элемента отправляется только после успешной оплаты заказа.

Запрос делаю через Javascript.
Сейчас сделал так: я отправляю запрос, мне возвращается ошибка: "Элемент не найден, 404".
Далее эту ошибку обрабатываю, отправляю запрос на создание элемента.

Всё работает корректно, элемент создаётся, проблем нет. Но при этом в консоль разработчика на сайте выбрасывается та самая ошибка: "запрос не удался, элемент не найден 404".
Я самоучка, но, предполагаю, что в консоли на боевом сайте никогда не должны появляться ошибки. Так ли это?

Можно сделать доработку в самом API, чтобы при подобном запросе он отдавал другой ответ, который будет сигналом для следующих действия, а не ошибку. Но по REST-api концепции при GET-запросе должна выдаваться именно ошибка.

Как лучше доработать данный функционал?

Comments

[twobomb]

Ну так просто не шлите 404.

[Lynn «Кофеман»]

> что в консоли на боевом сайте никогда не должны появляться ошибки

Нет. В консоли не должны появляться неожиданные необработанные ошибки В частности ошибки JS. А 404 это нормально и если вы его ожидаете и правильно обрабатываете, то в этом нет ничего плохого.

[Lynn «Кофеман»]

Но вообще, никто не мешает поменять api так что бы, например, сервер возвращал не 404, а 200 с описанием ошибки в теле.

[Andrew]

Я немного не понял вашу схему.
Вам нужно при заполнении данных:
1. Если элемент есть, перезаписать его
2. Нет - записать/создать
Так?
Что мешает на фронте всегда передавать данные и уже на бэке смотреть и отдавать нужное сообщение:
1. Ура! элемент создан
2. Окей, элемент перезаписан.

Т.е. всё что нужно делать фронту - отдавать данные и выводить сообщение.

Answer 1

[Владимир Коротенко]

Не делайте этот запрос!

Если без шуток, то статус 404 вполне информативен и нормален, вы его можете перехватить и обработать.
Кроме того используйте списки. Например для календаря

GET /api/getEvents/12.02.2020 -> возвращает список событий 0..N и 200 статус
GET /api/getEvents/12.02.2020/1 -> событие номер 1
POST /api/getEvents/12.02.2020 создание события

И так далее

Answer 2

[Vladimir Shapovalov]

Или сделать json-api, где будет возвращатся запись вида [status: error, message: "not found"].

Сделал я как то энпоинт /user/reset/{token} для сброса паролей у юзеров. Потом появился еще и сброс емейла, для тех кто потерял доступ к мылу или мыло забыл, появился ресет-пароль и ресет-емейл. А вот в клиенте изменить УРЛ я забыл. Что было дальше? Правильно, клиент думал что все путем, просто дурные клиенты всё день за днем неправильные токены подсовывают (которых нет а БД, 404). Пока через неделю при мердже совсем другой ветки репозитория не запустили автотесты, которые этот баг показали.