Хм.

Я имею в виду какую-то «пре-валидацию».

Например, если функция должна отправить сообщение юзеру, а по такому id юзера нет – это это _несомненно_ бизнес-операция (API отработало, база чекалась), и ответ должен быть 200.

Но если вместо id передана строка, а не число? Или null? Или объект!?
Логика, по-хорошему, должна перед тем как базу этим кормить – проверить, что аргументы и их типы верны.
И если не верны – то операция не будет выполнена, и это уже ошибка ПРОГРАММИСТА, который писал фронт, а не штатная ситуация на фронте.

Однако, архитектура сервера может быть и такой, что «сразу» параметры валидировать не получится, тогда уж увы.

«А чтобы понять, почему 403 – будем тело ответа парсить».

А откуда превалидатор знает какого типа должен быть параметр? От бизнеса. Значит это все равно часть бизнес операции

JSON схема может быть?

Для неверного пароля нужно тело парсить хоть при 200 хоть при 403

Ее все равно диктует бизнес

Так я и не говорил, что все мои перечисленные ошибки – обязательно nginx должен отдавать, а express всегда отвечать 200.

До эндпоинта-то запросы доходят. Мы ж не прокси, что сами не знаем, что принимаем.

Кстати, ещё есть GET-апи. Вот для него обилие кодов очень удобно, потому что «тело» обычно какое-нибудь бинарное.

404 – нет файла (но есть эндпоинт),
403 – неверна авторизация,
400 – что-то не передано или эндпоинт не тот.

Всем привет
Кто сталкивался с таким ошибкой '{object: bull prototype}', именно про авторизации, сделал console.log(res.cookies)

Null*

а зачем к себе в базу что-то класть?
почему не хочется использовать api crm всегда?

там ограничения на выполнение запросов, т.е. если тот же поисковик будет индексировать, я просто не смогу всех обслужить

ну и хочется сделать полнотекстовый поиск, elasticsearch, думаю в нем хранить хотя пока только мысли гоняю

Сильное ограничение? Можно очередь организовать, контролировать нагрузку
Синхронизация будет болью в любом случае
Хоть по расписанию, хоть в момент заказа

да, ты понимаешь, там боль самого API или я что-то не понимаю, там, чтобы нормально страницу вывести с категориями и товарами надо кучу запросов выполнить к API, плюс у товаров свои модификации и т.д.

А если только на запись читать из crm, а для операций чтения хранить кеш в локальной базе?

По хорошему тут подойдут теже решения что и для любой распределенной системы. У тебя eventual consistency.

У апи есть подписка на уведомление об изменении товара?

Это костыль. Всегда может случится так что прочитал - было всё хорошо, а в следующую секунду менеджер удалил

я вот и думаю, читать данные с CRM, ложить их в redis например, на сайте выводить из редиса, паралельно процесс работает непрерывно этот кеш обновляет, т.к. я не могу найти в API вообще данные о том, какой товар изменен или удален