Но относительно здоровому человеку ничего в себя силой вливать не надо.
За исключением сильной жары. Если температура воздуха выше +35℃, то рекомендуется делать 2-3 глотка минералки или изотоника каждые 10-20 минут, независимо от чувства жажды
Из Золотого Правила прямо следует, что нельзя делать другим ничего, чего они себе не хотят
Абсолютно не следует. Вы так и не смогли чётко, по шагам, показать такое следствие, просто потому, что его не существует. Ну или покажите пошагово, как это “они” самозарождается в правиле.
Зато из него НЕ следует, будто по желанию другого человека вы должны ограничиваться для него только тем, получение чего приемлемо для вас
Не следует. Желание другого человека в вашем правиле просто не учитывается. В нём есть только ваше нежелание какого-то действия по отношению к вам и запрет для вас такого же действия по отношению к другим. Интересы остальных побоку.
У действий ваших воображаемых бандитов тупо нет никакого убедительного объяснения
А оно им нужно? Вроде как в вашей системе достаточно желания, а обоснование совсем не требуется. В конце концов, хочу я стоять здесь, держась за руки с друзьями, вот и стою. Зачем мне что-то обосновывать?
С чего вдруг “не делай ДРУГИМ” направлено на себя?
А кто не должен делать? Другие? Или ты? Раз ты, значит императив “не делай” направлен на себя.
Следовательно, одним из видов того, чего не следует делать другим, будет “то, чего они сами себе не хотят”
Не следовательно. Здесь у вас нет логической связи с вашим правилом. Ещё раз. Правило в вашем изложении звучит как “Не делай другим того, чего не хочешь получить себе”. Формальное логическое дополнение этого правила - “Можешь делать с другими то, что ты приемлешь чтобы сделали с тобой”.
они прибежали после начала пожара, препятствуют его тушению силами местных жителей и прямым текстом сообщают о своём желании получить денег за “работу”
Ну вот совпал флеш-моб по времени с пожаром, что тут сделаешь. А тот господин, который обсуждает вопрос выкупа домов, так мы его вообще не знаем, он сам по себе.
То есть, их “пассивное стояние” – часть АКТИВНЫХ преступных действий.
То есть вся ваша философия построена на подборе удобной для вас трактовки действий людей. А у них своя трактовка и в ней вы агрессор, а они просто тут стоят.
Вот вы хотите, чтоб я сделал вам то, чего вы себе не хотите получить?
А какая разница? Желания другого человека в вашем правиле не учитываются. “Не делай” направлено на себя и “не хочешь себе” тоже направлено на себя.
вы не должны делать другим людям того, чего ОНИ СЕБЕ не хотят
Как легко у вас “того, что ВЫ себе не хотите” превращается “того, чего ОНИ себе не хотят”? Вот это и есть демагогические приёмы. Либо меняйте само правило, либо смиритесь с тем, что оно не работает.
Умному человеку достаточно одной формулы
Ровно потому, что две другие выводятся из первой строгими правилами математики. И если вы попробуете применить к своему правилу строгую формальную логику, то ВЫ в ОНИ не превратится ни при каком преобразованиию
это уже активное действие
Это пассивное стояние на месте, Активные действия будут с вашей стороны, если вы попробуете их оттащить.
всем известно, что они не просто так стоят по своей надобности
А ещё всем известно, что Солнце вращается вокруг Земли. Может у них флеш-моб “возьмёмся за руки, друзья”. И попробуйте доказать обратное.х
Но там ведь используется одно и то же подключение (сессия).
В HTTP вы тоже можете использовать одно подключение для серии запросов. Это не делает его сессионным. Вопрос в том, используются ли в обработке запроса данные этого соединения.
То есть, разные запросы могут обрабатываться разными экземплярами сервера
Это преимущество, которое даёт stateless, а не требование. К тому же, на входе вполне может стоять один балансировщик, который далее распределяет запросы между серверами/сервисами.
А как же аутентификация? В каждом запросе отправляется jwt (или что-то подобное)?
Да. Для случая JSON-RPC просто добавляем ещё одно поле в params.
Нет, это и есть словоблудие с вашей стороны. Вы берёте правило, в котором чётко сказано “того, чего не хочешь себе” и начинаете плясать вокруг, пытаясь вложить в эту фразу совершенно другой смысл. Обратная сторона этого правила - “Можно (но не обязательно) делать другим то, чего хочешь себе”. Это обычное построение формальной логики.
что неявно, но очевидно следует
Вообще-то оно не следует из УК. В УК РФ вы нигде не найдёте явного запрета убивать людей. Но, даже если такая фраза там бы была, то запрет убийства рыжих, шатенов, блондинов и даже лысых следовал бы из неё явно, так как люди с каким-либо цветом волос являются подмножеством всех людей. Опять таки формальная логика.
Золотое правило пОлно и универсально
Если оно такое полное и универсальное, то зачем тогда нужны все толкования и производные?
Не уйдут – аккуратно отнести в сторонку на руках, я ж не один, со мной толпа домочадцев и соседей.
А они друг за друга держатся. И их тоже немало. Попытаетесь их расцепить - это уже активное действие с вашей стороны. А если ещё и синяк оставите при этом, то это уже нанесения явного вреда.
А как заранее определить, что клиенту недоступно конкретное действие над конкретным элементом конкретного документа, если это определяется правилами бизнес-логики?
того, чего он не хочет получить себе от других – кирпичом по башке, например
Ну так он вас кирпичом по голове и не бьёт. А кнутом по спине он хочет. Вот вас кнутом по спине и бьёт.
из правила … логически выходит его частное производное
Вот так взяли и полностью поменяли смысл правила. А кто-то его поменяет так, как ему удобно. А третий в свою сторону. И что от правила останется?
активное причинение вреда действием
Почему? Вот группа людей плотно окружила фонтан (а именно из фонтанов в Риме брали воду) и стоит. Вы хотите пройти, а они не двигаются. Действий с их стороны нет. Но и воду набрать вы не можете.
WebSocket вполне себе может работать как stateless. То, что в нём на транспортном уровне есть постоянное соединение, не означает наличия состояние. В HTTP постоянное соединение тоже можно использовать (Connection: keep-alive начиная с HTTP/1.1).
Транспортному уровню вообще не должно быть дела до бизнес-логики. Его дело - принять от клиента запрос, отправить его маршрутизатору (промежуточный слой), получить от маршрутизатора ответ (или ошибку) и отправить его клиенту.
Золотое правило этики не работает. Например, по нему мазохист может вас бить и унижать, посколько не против, чтобы вы его били и унижали. А жаворонки могут будить сов в 5 утра, поскольку сами встают в это время.
при анархии ваше право “делать что угодно” ограничено моим правом не получать объективный вред от ваших действий
В древнем Риме пожарная служба приезжала на пожар, вставала вокруг и никого не подпускала, не давая тушить пожар и торгуясь с хозяином и соседями о сумме выкупа их домов. Но сами они вред никому не наносили.
Сам по себе JSON-RPC это не REST, это именно RPC-протокол, передаваемый любым транспортом.
Применительно к вашему джейсону все, что в representation будет обрабатываться логическим уровнем, все остальное (что выше) – транспортным.
Не совсем. Действие (PATCH) и ресурс - это тоже может быть бизнес-уровнем. Мы должны знать, разрешено ли текущему пользователю данное действие над данным полем данного ресурса, причём это может зависеть от текущего состояния ресурса (например, утверждение документа закрывает правки для всех, кроме руководителя). А это права/роли пользователей.
А я, собственно, пишу о том, что стоит разделять транспортный и бизнес-уровни, в том числе и в статусах ошибок, хотя никто не мешает задействовать и одновременно оба уровня. Ну а оппоненты утверждают, что “HTTP-статуса 403 хватит для любой ошибки авторизации”.
Насчёт аутентификации соглашусь, она слабо связана с бизнес-уровнем и может быть отдельным слоем. Хотя этот слой тоже может быть шире, чем один HTTP-статус 401. А вот авторизация вне бизнес-уровня особого смысла не имеет. Если какой-либо роли пользователя не разрешено изменять конкретное поле в конкретном типе документа при конкретном его статусе, то где это проверять, на уровне транспорта apache/nginx?
По стандарту должен, если с ним придёт соответствующий 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 и только если их недостаточно, то добавлять расширенную информацию. Я же за то, чтобы всегда использовать бизнес-ошибки, а транспортные ошибки оставить транспорту ну или, если хочется, использовать их параллельно.
За исключением сильной жары. Если температура воздуха выше +35℃, то рекомендуется делать 2-3 глотка минералки или изотоника каждые 10-20 минут, независимо от чувства жажды
Абсолютно не следует. Вы так и не смогли чётко, по шагам, показать такое следствие, просто потому, что его не существует. Ну или покажите пошагово, как это “они” самозарождается в правиле.
Не следует. Желание другого человека в вашем правиле просто не учитывается. В нём есть только ваше нежелание какого-то действия по отношению к вам и запрет для вас такого же действия по отношению к другим. Интересы остальных побоку.
А оно им нужно? Вроде как в вашей системе достаточно желания, а обоснование совсем не требуется. В конце концов, хочу я стоять здесь, держась за руки с друзьями, вот и стою. Зачем мне что-то обосновывать?
А кто не должен делать? Другие? Или ты? Раз ты, значит императив “не делай” направлен на себя.
Не следовательно. Здесь у вас нет логической связи с вашим правилом.
Ещё раз. Правило в вашем изложении звучит как “Не делай другим того, чего не хочешь получить себе”. Формальное логическое дополнение этого правила - “Можешь делать с другими то, что ты приемлешь чтобы сделали с тобой”.
Ну вот совпал флеш-моб по времени с пожаром, что тут сделаешь. А тот господин, который обсуждает вопрос выкупа домов, так мы его вообще не знаем, он сам по себе.
То есть вся ваша философия построена на подборе удобной для вас трактовки действий людей. А у них своя трактовка и в ней вы агрессор, а они просто тут стоят.
А какая разница? Желания другого человека в вашем правиле не учитываются. “Не делай” направлено на себя и “не хочешь себе” тоже направлено на себя.
Как легко у вас “того, что ВЫ себе не хотите” превращается “того, чего ОНИ себе не хотят”? Вот это и есть демагогические приёмы. Либо меняйте само правило, либо смиритесь с тем, что оно не работает.
Ровно потому, что две другие выводятся из первой строгими правилами математики. И если вы попробуете применить к своему правилу строгую формальную логику, то ВЫ в ОНИ не превратится ни при каком преобразованиию
Это пассивное стояние на месте, Активные действия будут с вашей стороны, если вы попробуете их оттащить.
А ещё всем известно, что Солнце вращается вокруг Земли. Может у них флеш-моб “возьмёмся за руки, друзья”. И попробуйте доказать обратное.х
В HTTP вы тоже можете использовать одно подключение для серии запросов. Это не делает его сессионным. Вопрос в том, используются ли в обработке запроса данные этого соединения.
Это преимущество, которое даёт stateless, а не требование. К тому же, на входе вполне может стоять один балансировщик, который далее распределяет запросы между серверами/сервисами.
Да. Для случая JSON-RPC просто добавляем ещё одно поле в params.
Нет, это и есть словоблудие с вашей стороны. Вы берёте правило, в котором чётко сказано “того, чего не хочешь себе” и начинаете плясать вокруг, пытаясь вложить в эту фразу совершенно другой смысл. Обратная сторона этого правила - “Можно (но не обязательно) делать другим то, чего хочешь себе”. Это обычное построение формальной логики.
Вообще-то оно не следует из УК. В УК РФ вы нигде не найдёте явного запрета убивать людей. Но, даже если такая фраза там бы была, то запрет убийства рыжих, шатенов, блондинов и даже лысых следовал бы из неё явно, так как люди с каким-либо цветом волос являются подмножеством всех людей. Опять таки формальная логика.
Если оно такое полное и универсальное, то зачем тогда нужны все толкования и производные?
А они друг за друга держатся. И их тоже немало. Попытаетесь их расцепить - это уже активное действие с вашей стороны. А если ещё и синяк оставите при этом, то это уже нанесения явного вреда.
А как заранее определить, что клиенту недоступно конкретное действие над конкретным элементом конкретного документа, если это определяется правилами бизнес-логики?
Ну так он вас кирпичом по голове и не бьёт. А кнутом по спине он хочет. Вот вас кнутом по спине и бьёт.
Вот так взяли и полностью поменяли смысл правила. А кто-то его поменяет так, как ему удобно. А третий в свою сторону. И что от правила останется?
Почему? Вот группа людей плотно окружила фонтан (а именно из фонтанов в Риме брали воду) и стоит. Вы хотите пройти, а они не двигаются. Действий с их стороны нет. Но и воду набрать вы не можете.
WebSocket вполне себе может работать как stateless. То, что в нём на транспортном уровне есть постоянное соединение, не означает наличия состояние. В HTTP постоянное соединение тоже можно использовать (Connection: keep-alive начиная с HTTP/1.1).
Транспортному уровню вообще не должно быть дела до бизнес-логики. Его дело - принять от клиента запрос, отправить его маршрутизатору (промежуточный слой), получить от маршрутизатора ответ (или ошибку) и отправить его клиенту.
Золотое правило этики не работает. Например, по нему мазохист может вас бить и унижать, посколько не против, чтобы вы его били и унижали. А жаворонки могут будить сов в 5 утра, поскольку сами встают в это время.
В древнем Риме пожарная служба приезжала на пожар, вставала вокруг и никого не подпускала, не давая тушить пожар и торгуясь с хозяином и соседями о сумме выкупа их домов. Но сами они вред никому не наносили.
Сам по себе JSON-RPC это не REST, это именно RPC-протокол, передаваемый любым транспортом.
Не совсем. Действие (PATCH) и ресурс - это тоже может быть бизнес-уровнем. Мы должны знать, разрешено ли текущему пользователю данное действие над данным полем данного ресурса, причём это может зависеть от текущего состояния ресурса (например, утверждение документа закрывает правки для всех, кроме руководителя). А это права/роли пользователей.
А я, собственно, пишу о том, что стоит разделять транспортный и бизнес-уровни, в том числе и в статусах ошибок, хотя никто не мешает задействовать и одновременно оба уровня. Ну а оппоненты утверждают, что “HTTP-статуса 403 хватит для любой ошибки авторизации”.
Насчёт аутентификации соглашусь, она слабо связана с бизнес-уровнем и может быть отдельным слоем. Хотя этот слой тоже может быть шире, чем один HTTP-статус 401.
А вот авторизация вне бизнес-уровня особого смысла не имеет. Если какой-либо роли пользователя не разрешено изменять конкретное поле в конкретном типе документа при конкретном его статусе, то где это проверять, на уровне транспорта apache/nginx?
По стандарту должен, если с ним придёт соответствующий 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 и только если их недостаточно, то добавлять расширенную информацию. Я же за то, чтобы всегда использовать бизнес-ошибки, а транспортные ошибки оставить транспорту ну или, если хочется, использовать их параллельно.