так и я о том же, что не стоит путать тёплое с мягким
http status code - для ошибок уровня http транспорта
не стоит туда пихать ошибки уровня приложения

если логика приложения такая, что в ответ на запрос нужно редиректнуть, то тоже отвечать 200, а не 301?

или речь только о 4хх и 5хх?

кстати, если браузер должен редиректнуть, то да, стоит 200 ответить

тут вопрос кто выполняет редирект?

т.к. по хттп редиректам, библиотеки автоматом засылают GET запрос туда, куда указано в Location заголовке

т.е. эффект может быть немного не тот, что разраб ожидает

👍

еще есть вариант когда отдаешь какому-то сервису данные по АПИ, например в google news. и если новость удалилась, то всё же стоит вернуть 404, нежели 200.
Я обычно возвращаю для ошибок 4xx + описание

Хай. Как дела?

Совпадение :)?

Не думаю

В том-то и дело, что транспорт. Только вот функции веб-сервера в случае апи может выполнять и само веб-приложение. Поверх апи-сервиса может быть сколько угодно абстракций, а может быть  нисколько. Клиент ничего об этом не знает, но хочет иметь ответ соответвующий стандарту.  Клиент работает с абстрактным единым веб-сервером. Когда что-то работает не так и ты получаешь 200, то выглядит как-то неожиданно. 301 не выглядит ни исключением, ни проблемой, он соответствующе обрабатывается клиентским фреймворком например.

SRP и ISP никто не отменял.
Хотите валить все в кучу - протокол, транспорт, интерфейс - ваше право, заплатите втридорога за поддержку и траблшутинг.
В вашем примере нарушен ISP, когда апи выполняет еще и роль веб сервера.
Клиент не должен работать с веб сервером, клиент должен работать с апи. С веб сервером должна работать подсистема транспорта этого апи и пользователь может о ней ничего не знать.

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

По мне так эта одна из ключевых проблем restfull api. Вспомнить хотя бы рельсовые костыли в виде _method=put/delete/post

А самое забавное тут то, что "делаем под спецификацию http", а на деле используют http/2 делая вид что это одно и то же. Ведь если трансляцию из одного в другое делает веб сервер, то ведь это "не считается"

ой-ой, SRP-ISP, мне кажется это чуть-чуть про другое, не? 😂

Нет. Мы же про архитектуру приложения/апи говорим

окей

а ты случаем не троллишь? не, ну реально мы тут с пацанами под пиво ржём сидим, как завернуло тут и что-то из OSI, и SRP, ISP, очевидно и весь SOLID здесь. уважаемые люди интересуются - чё куришь, брат? 🤔

Обсуждение началось с проектирования интерфейса апи. Я поделился опытом и привёл аргументацию почему считаю один подход лучше другого. Какие проблемы встречаются и какие принципы нарушаются при предложенных решениях.

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