а 400 как раз адекватно можно обработать

в том же jquery.form

Там вообще некоторые браузеры могут при xhr сохранять методы. То есть может редиректить на POST :D

можно конечно и с 200, и ключ туда какой то зашить.
но через http код ошибки – это более правильный и стандартный подход

ну и в целом по опыту, это намного удобнее, чем какой то ключ

в логах сразу видно

и можно нетолько 400 использовать

на auth ошибки допустим 403

и т.п.

мне кажется, что на реальном примере все со всеми согласны и знают как делать )

удобно)

никто этого не говорил. Говорили вообще про ошибки изначально. Если у тебя бизнес-логика такая, что тебе нужно редирект на урл, который ты получаешь в качестве успешного ответа, то ясен красен, что АПИ про этот редирект знать не должно! Апи возвращает ответ, который ожидает твой фронт.

Но это супертупо, если апи вместо ответа со ссылкой тебе будет возвращать 200 и сообщение, знаешь, вот вместо урла возьми тут ошибки...

а колбек onError у тебя не срабатывает, потому что он вообще-то success получил

то есть когда мы по логике приложения хотим перекинуть пользователя на другую страницу и возвращаем 200 (а не 301) это не супертупо.
а когда у нас ошибки то возвращать 200 (вместо 400) уже супертупо?

я предлагал всегда возвращать 200 и ответ вида { result: {}, error: {} }
и айксовый onSuccess будет проверять наличие response.error
и вызывать обработчик исполняющий переход браузера на result.url в случае отсутствия ошибок
и показывать ошибки в противном случае

конечно
стандартный аяксовый OnError в моей логике должен срабатывать только в случае ошибок веб-сервера (а не приложухи)

А кто то замерял начало спора?кажется, уже часов 18 идёт с небольшим перерывом на сон 😅

Засветили сегодня rspec на первом в Питере)

Ruby жив!

интересно, специально на русский перевели itы

Неплохо, кстати, и квери на месте, и презентеры