По стандарту должен, если с ним придёт соответствующий Cache-Control. А 501 вообще по умолчанию кэшируемый.
На какой ещё протокол его можно применить?
Да на любой. Основная идея REST - это управление ресурсами через их полные или частичные представления. Вот вам REST запрос поверх JSON-RPC через WebSocket:
Анархия – это отсутствие того, кто за меня решает, как мне жить.
А зачем нужен шериф, если каждый сам решает, как ему жить? Вот решил кто-то ограбить ваш дом, так это его решение. Почему вы или шериф можете за него решать, что ему нельзя этого делать?
То есть статус транспортного уровня. Ну так давайте оставим транспортный уровень транспорту. Тем более, что кэширование управляется не только HTTP-статусом (за исключением 1xx), но и дополнительными полями ответа (RFC 9111). И при желании можно включить кэширование ответа с любым финальным статусом. Ну и не забываем, что REST - это не только про HTTP, но и про любой другой протокол, в том числе и не имеющий никаких встроенных статусов.
У меня, допустим, есть один конкретный обработчик описанной Вами ситуации со страницей в одном единственном месте, в одном единственном сервисе, предоставляющем страницы книги.
То есть в остальном месте у вас нет бизнес-логики? И если я запрошу /api/book/350 то ваш сервер не будет проверять, есть ли у меня права доступа к API и книге?
Зачем сервису аккаунта пользователя знать что-то про ошибку бизнес-логики сервиса страниц?
А зачем ему это знать? У него свои ошибки. Но, опять же, вы ведь проверяте доступ пользователя к API пользователей и к конкретному запрошенному пользователю? То есть место для выдачи разных бизнес-кодов ошибок у вас уже есть. А транспортный код может быть один, а может его и вовсе нет в используемом транспорте.
Ну так у вас так и так есть какие-то обработчики ошибок бизнес-логики. Где-то же вы проверяете, есть ли у пользователя доступ к API, книге и странице. Что вас заставляет возвращать одну и ту же неинформативную ошибку для трёх разных вариантов? Ну а хочется озвращать ещё и транспортную, так добавьте параметр в обработчик ошибок, будут там бизнес-код и транспортный код ошибки.
Как-будто и используя систему ошибок HTTP тоже можно…
Можно, но недостаточно информативно. Скажем в ответ на GET /api/book/350/page/12 вам вернулся HTTP-ответ 403 Forbidden. К чему вам запрещён доступ - к API в целом, к книге или к странице?
Вы ж просто расширите WebSocket транспортными ошибками, нет?
Зачем в WebSocket транспортные ошибки из HTTP, если достаточно использовать ошибки бизнес-логики?
Как-будто Вы с автором статьи говорите ровно об одном и том же, но разными словами.
Не совсем. Автор статьи предлагает использовать статусы HTTP и только если их недостаточно, то добавлять расширенную информацию. Я же за то, чтобы всегда использовать бизнес-ошибки, а транспортные ошибки оставить транспорту ну или, если хочется, использовать их параллельно.
В точности описания ошибки. Если вам вернулось “нет такой страницы” вы, скорее всего, будете проверять, а есть ли другие страницы. А если “нет такой книги”, то и смысла искать другие страницы просто нет.
Ну так если мы всё равно добавляем поле с ошибкой в ответ и оно более информативно, чем статус HTTP, то есть смысл для унификации всегда добавлять такое поле. И не гадать, где оно есть, где его нет.
если у вас книжный магазин, то покупателю нельзя производить никакие изменения в книгах, поэтому дополнительных пояснений к ошибке 403 не понадобится
А если это был GET, то куда ему нельзя, в книгу вообще или именно на 12 страницу?
При использовании HTTP и WebSocket понятие единого интерфейса не применимо
А вот если использовать свою систему ошибок, не полагаясь на протокол, то единый интерфейс вполне себе возможен. Просто в WebSocket будет небольшой оверхед на id запроса и глагол (действие). А вся остальная часть будет той же самой.
Если /api/orders/999 не существует — это 404 Not Found. Можно добавить JSON для вывода пользователю, но необязательно.
А если /api/book/350/page/12 вернул 404, то чего именно не существует - книги с id 350, страницы 12 в этой книге или вообще api? А если 403, то на что именно у клиента нет разрешения - на доступ к книге вообще, к конкретной странице или к операции (PUT/PATH/DELETE)?
Клиенту приходится проверять HTTP-статус и поле в JSON.
Но, чтобы понять, что именно произошло, клиенту и так придётся откуда-то эту информацию брать.
Одно из ключевых — единый интерфейс. HTTP уже реализует этот интерфейс, и статусы — его важная часть.
А что делать, если мы хотим использовать REST одновременно и по HTTP и по WebSocket? У последнего никаких статусов нет. Что в таком случае означает “единый интерфеейс”?
В попытках понравиться электорату не обязательно что-то делать. Достаточно обещать. Ну можно ещё вносить заведомо непроходные законопроекты, типа МРОТ в 100500 рублей или трёхдневной рабочей недели за ту же зарплату.
В первый раз они летели из Франкфурта-на-Майне в Толмачёво с запасным в Барнауле. В зоне Толмачёво оказалось, что погода плохая. 10 минут покрутились, решили сесть, но на заходе был сильный боковой ветер и решили уйти на запасной. В Барнауле погода тоже была ниже метеоминимума, поэтому экипаж решил уйти в Омск. А дальше в телеграмме очень интересно
ПО ПОКАЗАНИЯМ ЭКИПАЖА, НА БОРТУ ВС 4800 КГ ТОПЛИВА (ПО ДАННЫМ МСРП [самописца] - 4064 КГ)
В НАБОРЕ ВЫСОТЫ СРАБОТАЛА СИГНАЛИЗАЦИЯ О РЕЗЕРВНОМ ОСТАТКЕ ТОПЛИВА 2600 КГ, ПО ОБЬЯСНЕНИЯМ ЭКИПАЖА ОСТАТОК СОСТАВЛЯЛ 3600 КГ (ПО ДАННЫМ МСРП - 3157 КГ).
КОМИССИЯ ПО РАССЛЕДОВАНИЮ УСТАНОВИЛА, ЧТО ЭКИПАЖЕМ ДОПУСКАЛАСЬ ВОЗМОЖНОСТЬ ПОСАДКИ С НЕРАБОТАЮЩИМИ ДВИГАТЕЛЯМИ
Но эти десять рейсов в день, они же не абстрактные, они же куда-то в другие аэропорты. И отменив их, вы отмените их и в других аэропортах. В результате там, где было пятнадцать рейсов в день, станет восемь и аэропорт, по вашим меркам, перейдёт из нормальных в убыточные. И эта волна будет катиться, пока, в лучшем случае, не останутся только самые крупные аэропорты.
Если вы не будете создавать на рынке условия честной конкуренции
Тогда давайте сначала определимся, что такое честная конкуренция. Вот есть два завода, выпускающих одну и ту же продукцию. Что надо сделать, чтобы конкуренция стала “честной”? А теперь добавляем вводные. Первый завод находится в северной климатической зоне и должен строить/поддерживать капитальные здания и платить за отопление. Сырьё в него доставляется за тысячи километров. Средняя зарплата в регионе достаточно высокая и работать за копейки на завод никто не пойдёт. Второй завод в южной зоне, где достаточно поставить навесы над станками. Сырьё производится на соседней улице. Работники согласны на миску риса в день. У какого завода продукция будет иметь меньшую себестоимость и как вы предлагаете создать “честную” конкуренцию? Добавить второму заводу гандикап?
Политика развития собственной промышленности - это ни в коем случае не честная конкуренция. Как правило это протекционизм - предоставление преференций своим предприятиям и создание барьеров для зарубежных.
отказ от явно выраженной архитектуры MVC, декларирование стандарта CMA, когда классы рождают массив метаданных, которые могут быть преобразованы во что угодно
“Массив метаданных” порождается контроллером (contoroller). “Преобразуется во что угодно” в нужном виде (view). А к моделям (model) контроллер обращается для получения исходных данных. Так что никуда вы от MVC не ушли.
то нам нельзя никого как-либо ограничивать, вынуждать или спонсировать - это неконкурентные методы.
раз они демпингуют
А они демпингуют? По какой цене продавались эти магниты в самом Китае? Если они там были заметно дороже, то что мешало скупать их у китайского производителя подчистую по низкой цене а потом продавать обратно китайским потребителям по высокой, даже не вывозя их из Китая?
По стандарту должен, если с ним придёт соответствующий Cache-Control. А 501 вообще по умолчанию кэшируемый.
Да на любой. Основная идея REST - это управление ресурсами через их полные или частичные представления. Вот вам REST запрос поверх JSON-RPC через WebSocket:
А зачем нужен шериф, если каждый сам решает, как ему жить? Вот решил кто-то ограбить ваш дом, так это его решение. Почему вы или шериф можете за него решать, что ему нельзя этого делать?
То есть статус транспортного уровня. Ну так давайте оставим транспортный уровень транспорту. Тем более, что кэширование управляется не только HTTP-статусом (за исключением 1xx), но и дополнительными полями ответа (RFC 9111). И при желании можно включить кэширование ответа с любым финальным статусом. Ну и не забываем, что REST - это не только про HTTP, но и про любой другой протокол, в том числе и не имеющий никаких встроенных статусов.
То есть в остальном месте у вас нет бизнес-логики? И если я запрошу /api/book/350 то ваш сервер не будет проверять, есть ли у меня права доступа к API и книге?
А зачем ему это знать? У него свои ошибки. Но, опять же, вы ведь проверяте доступ пользователя к API пользователей и к конкретному запрошенному пользователю? То есть место для выдачи разных бизнес-кодов ошибок у вас уже есть. А транспортный код может быть один, а может его и вовсе нет в используемом транспорте.
Да? Как мне их получить на WebSocket? Ведь REST не прибит гвоздями к HTTP.
Ну так у вас так и так есть какие-то обработчики ошибок бизнес-логики. Где-то же вы проверяете, есть ли у пользователя доступ к API, книге и странице. Что вас заставляет возвращать одну и ту же неинформативную ошибку для трёх разных вариантов? Ну а хочется озвращать ещё и транспортную, так добавьте параметр в обработчик ошибок, будут там бизнес-код и транспортный код ошибки.
Можно, но недостаточно информативно. Скажем в ответ на GET /api/book/350/page/12 вам вернулся HTTP-ответ
403 Forbidden. К чему вам запрещён доступ - к API в целом, к книге или к странице?Зачем в WebSocket транспортные ошибки из HTTP, если достаточно использовать ошибки бизнес-логики?
Не совсем. Автор статьи предлагает использовать статусы HTTP и только если их недостаточно, то добавлять расширенную информацию. Я же за то, чтобы всегда использовать бизнес-ошибки, а транспортные ошибки оставить транспорту ну или, если хочется, использовать их параллельно.
В точности описания ошибки. Если вам вернулось “нет такой страницы” вы, скорее всего, будете проверять, а есть ли другие страницы. А если “нет такой книги”, то и смысла искать другие страницы просто нет.
Ну так если мы всё равно добавляем поле с ошибкой в ответ и оно более информативно, чем статус HTTP, то есть смысл для унификации всегда добавлять такое поле. И не гадать, где оно есть, где его нет.
А если это был GET, то куда ему нельзя, в книгу вообще или именно на 12 страницу?
А вот если использовать свою систему ошибок, не полагаясь на протокол, то единый интерфейс вполне себе возможен. Просто в WebSocket будет небольшой оверхед на id запроса и глагол (действие). А вся остальная часть будет той же самой.
Да читатель этой библиотеки. Что ему сказать при такой ссылке - “нет книги” или “нет страницы”?
А если /api/book/350/page/12 вернул 404, то чего именно не существует - книги с id 350, страницы 12 в этой книге или вообще api? А если 403, то на что именно у клиента нет разрешения - на доступ к книге вообще, к конкретной странице или к операции (PUT/PATH/DELETE)?
Но, чтобы понять, что именно произошло, клиенту и так придётся откуда-то эту информацию брать.
А что делать, если мы хотим использовать REST одновременно и по HTTP и по WebSocket? У последнего никаких статусов нет. Что в таком случае означает “единый интерфеейс”?
В попытках понравиться электорату не обязательно что-то делать. Достаточно обещать. Ну можно ещё вносить заведомо непроходные законопроекты, типа МРОТ в 100500 рублей или трёхдневной рабочей недели за ту же зарплату.
В первый раз они летели из Франкфурта-на-Майне в Толмачёво с запасным в Барнауле. В зоне Толмачёво оказалось, что погода плохая. 10 минут покрутились, решили сесть, но на заходе был сильный боковой ветер и решили уйти на запасной. В Барнауле погода тоже была ниже метеоминимума, поэтому экипаж решил уйти в Омск. А дальше в телеграмме очень интересно
Но эти десять рейсов в день, они же не абстрактные, они же куда-то в другие аэропорты. И отменив их, вы отмените их и в других аэропортах. В результате там, где было пятнадцать рейсов в день, станет восемь и аэропорт, по вашим меркам, перейдёт из нормальных в убыточные. И эта волна будет катиться, пока, в лучшем случае, не останутся только самые крупные аэропорты.
Плохо. Всё раздадим, себе ничего не останется, ни трусов, ни крестика.
Вы уж определитесь, либо трусы наденьте, либо крестик снимите.
Тогда давайте сначала определимся, что такое честная конкуренция. Вот есть два завода, выпускающих одну и ту же продукцию. Что надо сделать, чтобы конкуренция стала “честной”?
А теперь добавляем вводные.
Первый завод находится в северной климатической зоне и должен строить/поддерживать капитальные здания и платить за отопление. Сырьё в него доставляется за тысячи километров. Средняя зарплата в регионе достаточно высокая и работать за копейки на завод никто не пойдёт. Второй завод в южной зоне, где достаточно поставить навесы над станками. Сырьё производится на соседней улице. Работники согласны на миску риса в день.
У какого завода продукция будет иметь меньшую себестоимость и как вы предлагаете создать “честную” конкуренцию? Добавить второму заводу гандикап?
Политика развития собственной промышленности - это ни в коем случае не честная конкуренция. Как правило это протекционизм - предоставление преференций своим предприятиям и создание барьеров для зарубежных.
“Массив метаданных” порождается контроллером (contoroller). “Преобразуется во что угодно” в нужном виде (view). А к моделям (model) контроллер обращается для получения исходных данных.
Так что никуда вы от MVC не ушли.
то нам нельзя никого как-либо ограничивать, вынуждать или спонсировать - это неконкурентные методы.
А они демпингуют? По какой цене продавались эти магниты в самом Китае? Если они там были заметно дороже, то что мешало скупать их у китайского производителя подчистую по низкой цене а потом продавать обратно китайским потребителям по высокой, даже не вывозя их из Китая?
del