Думаю это госуха просто

эх, но в тесте .to eq(GroupTag.first.id)

пример
есть эндпоинт /edit который в зависимости от настроек пользователя должен либо редиректнуть браузер на страницу редактирования сущности, либо отобразить edit in place форму для редактирования, либо вернуть ошибку если пользователю это действие запрещено
по вашей логике и "редирект" и отображение формы должно возвращаться с кодом 200
а ошибка почему-то с кодом 400
хотя с точки зрения приложения это все валидные ответы. а понятие "ошибка" это ошибка только в пользовательском понимании. для приложения это просто еще одна ветка исполнения когда надо не новые элементы на страницу встраивать, а подсветить красненьким уже существующие или вывести модалку "access denied"

Мне кажется не важно как это выглядит, главное, чтобы было единое соглашение как писать все запросы на проект / экосистему проектов.
И это могут быть даже редиректы в API. Главное, чтобы те кто занимаются проектом (и фронт и бэк) - знали об этом.

да, контракты это самое важное

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

и у меня ощущение, что мне пытаются доказать, что этот подход плох
хотя именно он используется в api GraphQL, но что-то я не слышу что бы кто-то говорил "api graphgl - говно"

Не, это мне просто нравится по русски писать, не могу нормально на английском сформулировать спеку

да постоянно кто-то говорит "api graphgl - говно"

у тебя возможно, нет прямой связи с фронтендерами)

@darigaaz а 204 No Content на delete возвращаете?

Мне кажется, что 2хх и 4хх - это нормальные коды, чтобы их возвращать из апи и обрабатывать на клиенте, потому что они про клиентские ошибки и успехи. Можно и в 200 ок возвращать ошибки, но многие тулзы различают success/error ответы, что позволит чище написать обработку ответа.

3хх - перенаправление - можно использовать, если клиент умеет с ними работать, но в случае с бразуером, то браузер скорее всего перехватит и сам сделает редирект (можно это использовать, когда нужно). Кстати, интересный вопрос для меня. А можно ли не дать браузеру выполнить редирект и самому обработать ответ? 🤔

5хх - что-то пошло не так :) Никуда от них не деться, придется обрабатывать/ловить на клиенте.

1хх - никогда не приходилось вручную их ставить. Наверное, как и с 3хх, это может быть нужно в редких случаях.

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

А есть пример, когда это пригодилось?

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

👋 Всем привет, вдруг есть те кто использует Jenkins X? Поделитесь опытом, особенно круто если был переезд с обычного Jenkins.

а что это такое? оО

а какие могут быть трудозатраты? я не очень понимаю, чем код вроде (грубо)

apiCall(onSuccess,  onError)

лучше, чем

apiCall(onResponse)

onResponse {
  if success {
   ... 
  else
    ...
  }
}

все равно будет разделение/ветвление. Только с кодами можно сделать это с помощью библиотек и код станет чище

например.
есть эндпоинт, который должен возвращать список Item'ов, использовался для динамической подгрузки контента на странице (содержимое заказа)
и в какой-то момент пользователи начали жаловаться что иногда оно выбивает ошибку
ручная проверка показала, что действительно, иногда возвращается 404
и человек сидел и много часов искал несуществующий баг в коде
а все оказалось банальнее - на одном из round-robin серверов были какие-то проблемы с диском/процом, те какая-то железячная проблема. в итоге сервер заменили (это была виртуалка) и все ок

эм, а если бы один из серверов начал возвращать дефолтную страницу nginx-а c 200 ok?

тогда бы сразу увидели что там 200, но неправильное body, отличающееся от {result: {}, error: {}} и стало бы ясно что косяк не в апи, а в веб-сервере

а почему тело при 200 видно, а при 400 нет?