Здравствуйте, Ночной Смотрящий, Вы писали:

P>>Я пишу о том, как это уже работает внутри экосистемы. И с этим работают не только аритекторы и разработчики приложений, но и ops, l2, qa и тд.

НС>Каким образом они работают? Я не понимаю кто и в какой момент увидит этот хидер.

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

P>>Что именно ты ждешь? Код, контакт, или запись видео? Внятно вопрос сформулируй.

НС>Я жду ответа на простой вопрос: "кто будет твой нестандартный хидер читать"?

Непосредственно читать-писать будет конкретный пакет, который отвечает за капабилити или продуктовый если его команда решит все вручную пилить. Есть конвеншн — все документировано.

В итоге какой бы ты сервис ни взял, все единообразно

Здравствуйте, Ночной Смотрящий, Вы писали:

M>>Если запрос применим в состояниях s1 и s2, то состояние после выполнения запроса одно и то же: req(s1) == req(s2). На практике для безопасного повторения запросов в системах со многими акторами хотелось бы больших гарантий.
НС>В распределенных системах это вряд ли реализуемо, так как упирается в САР-теорему. Максимум можно такое обеспечить для асинхронных операций, и то это будет та еще эквилибристика.
А что сложного? Если у нас REST, то CAP нам не мешает. Мы уже более-менее согласились на eventual consistency. Поэтому распределенной "моментальной" консистентности и не требуется. A и P есть в рамках отдельной системы. Когда-нибудь C тоже будет достигнута. Например, на десятую повторную отправку можно делать алерты и идти ругаться с владельцами лежащего сервиса и девопсами. Т.е. чинить availaiblity/consistency. В рамках eventual consistency уже могут быть различные варианты и техники реализации (те же CRDT-типы в разных вариациях). Ну и вообще, у нас же "Representational State Transfer". У нас операций нет. Мы просто иногда делимся представлением своего локального состояния. В этом плане отправка состояния по HTTP мало чем отличается от "асинхронной отправки". Ну да, мы поделились своим состоянием. Сервер когда-нибудь поделился своим. И мы должны более-менее одинаково обрабатывать ситуации, когда ответ пришел синхронно (в ответ на "первый" запрос) и асинхронно (в ответ на повторо или что-то само изменилось на сервере и он послал уведомление в очередь сообщений).

Здравствуйте, Ночной Смотрящий, Вы писали:

M>>Нет в HTTP и API-специфичных вещей. Например, я обычно делаю заголовок X-Api-Warning стандартным в ответах (в значениях — коды, которые можно посмотреть в документации по конкретному сервису). Основной сценарий — извещать клиента о том, что его запросы перестают соответствовать требованиям и нужно бы что-то сделать.
НС>И кто будет твой нестандартный хидер читать?
Я же один из вариантов написал — service mesh. Например, Istio, Envoy, Kong или Conduit. Не так сложно будет убедить девопсов настроить мониторинг заголовков "из коробки". И будет у каждого пользователя сервиса метрика, от которой они не смогут отказаться. И вот если бы был стандартный заголовок, он бы с большой вероятностью уже поддерживался этими продуктами. Ну и да, пользователи сервиса тоже могут это реализовывать. Я бы без проблем сделал метрику и alert на такие предупреждения у тех сервисов, которые я вызываю. Даже если бы они были разные для каждого сервиса.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>·>Я ещё понимаю, если посылать номер версии в хедере "Server" или каком-нибудь "X-My-API-Version".
НС>Это тоже бессмысленно, потому что в нормальном REST url будет вида /api/vXX/collection. И в рамках конкретного vXX никаких ломающих изменений и устаревших API в принципе быть не может.
Не может, конечно. Но есть, и будет есть всегда! Баги всё ещё не отменили. Поэтому знать версии всех компонентов — must have. Сильно облегчает поиск проблем.

Здравствуйте, Ночной Смотрящий, Вы писали:

P>> Обычно люди, которые используют тот или иной API, делают это не от балды, а осознанно, потому можно ожидать, что они будут пользоваться такими вещами.
НС>Это все абстрактно. Давай конкретно. Вот есть некий API. К нему кто то написал клиента и использует в своем софте. Вдруг в хидере начинает приходить сообщение о том, что это API устарело. Кто это сообщение увидит?
Клиент и увидит. Я такой заголовок обычно включаю в публичный API своего сервиса сразу. Даже если он "пока" не используется. Поэтому когда через 3 месяца я удалю поддержку старого API и клиент придет жаловаться, у меня будут аргументы. Заголовок был документирован? Был. Я его выдавал? Выдавал. Три месяца — разумный срок? Да вроде разумный. Кто решил не делать мониторинг заголовка и сам себе злобный буратино?

Здравствуйте, ·, Вы писали:

·>Да и у емейла больше шанса, что его прочитают и отреагируют.
Совершенно не факт. Это у вас какая-то идеальная корпорация в вакууме. На практике там будет "ой, а мы не заметили". Или "ой, а на тот момент у нас были другие приоритеты и потом мы забиыли". Или вообще "а мы сервис только месяц назад получили, нас никто об изменениях не уведомлял". А так у меня все прекрасно получается. Письма я отправил всем, кому мог и кого знал (да еще и не один раз). Если вдруг не заметили — API выдавало предупреждения уже 3 месяца. Вон, в Istio нарисовано же в метриках. Так что в том, что у них там что-то перестало работать, виноват совсем не я.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>И в рамках конкретного vXX никаких ломающих изменений и устаревших API в принципе быть не может.
А сколько мы будет этот vXX поддерживать, если у нас уже есть vYY и даже vZZ? И кто будет оплачивать поддержку этого vXX в течение следующих 5 лет? И ладно бы это был внешний API (там как раз могут найтись клиенты с деньгами). А вот если API внутренний и другие ищут предлоги вообще ничего не делать?

Здравствуйте, ·, Вы писали:

P>>У нас внутри экосистемы подобные механизмы документированы и поддерживаются всеми клиентам. Консумер или берет такой клиент, или пилит свой с учетом конвеншна.
·>Ты так и не обосновал, зачем это пихать в каждый ответ. Чем это принципиально отличается от простой публикации changelog консьюмерам.

changelog содержит мизерное количество информации — название, ссылка на тикет, подробности, каменты, пул-реквест и тд. Отсюда далеко не всегда ясно, каким именно будет поведение конкретной системы. Соответсвенно, придется 1. прогнать тесты для всех n-систем/сервисов 2. надеяться, что в тестах будет прокрыта именно та самая ветка(и тут надо вспомнить, что не существует таких гарантий).
Т.е. все равно придется подкрутить мониторинг, что бы он хоть как то детектил проблемы, на случай п.2
А так у нас сразу есть звоночек от мониторинга — на сервисах 0, 8, 124 варнинги, реквест-респонс прилагаются. дальше l2 разбирается, что откуда куда пришло, по трейсингу, и дает знать команде соответсвующего сервиса, что у них чтото там не то.

·>Я ещё понимаю, если посылать номер версии в хедере "Server" или каком-нибудь "X-My-API-Version". Так консумеры могут догадаться, что с v1.2.3 работало, а с v1.2.4 что-то вдруг подглючивать стало, значит стоит поподробнее changelog почитать. Но что делать с Warning?

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

Здравствуйте, maxkar, Вы писали:

M>·>Да и у емейла больше шанса, что его прочитают и отреагируют.
M>Совершенно не факт. Это у вас какая-то идеальная корпорация в вакууме. На практике там будет "ой, а мы не заметили". Или "ой, а на тот момент у нас были другие приоритеты и потом мы забиыли". Или вообще "а мы сервис только месяц назад получили, нас никто об изменениях не уведомлял". А так у меня все прекрасно получается. Письма я отправил всем, кому мог и кого знал (да еще и не один раз). Если вдруг не заметили —
Ну если клиент важный и платит много денег, то можно добиться реакции на письмо. Если на мыло не отвечают совсем, то можно даже позвонить и даже ногами прийти.

M>API выдавало предупреждения уже 3 месяца. Вон, в Istio нарисовано же в метриках.
А это бесмысленная попытка решать административные проблемы техническими средствами.

Здравствуйте, Pauel, Вы писали:

P>Здравствуйте, ·, Вы писали:

P>>>У нас внутри экосистемы подобные механизмы документированы и поддерживаются всеми клиентам. Консумер или берет такой клиент, или пилит свой с учетом конвеншна.
P>·>Ты так и не обосновал, зачем это пихать в каждый ответ. Чем это принципиально отличается от простой публикации changelog консьюмерам.
P>changelog содержит мизерное количество информации — название, ссылка на тикет, подробности, каменты, пул-реквест и тд. Отсюда далеко не всегда ясно, каким именно будет поведение конкретной системы. Соответсвенно, придется 1. прогнать тесты для всех n-систем/сервисов 2. надеяться, что в тестах будет прокрыта именно та самая ветка(и тут надо вспомнить, что не существует таких гарантий).
В changelog в любом случае можно поместить несравненно больше информации, чем в хедер.

P>Т.е. все равно придется подкрутить мониторинг, что бы он хоть как то детектил проблемы, на случай п.2 А так у нас сразу есть звоночек от мониторинга — на сервисах 0, 8, 124 варнинги, реквест-респонс прилагаются. дальше l2 разбирается, что откуда куда пришло, по трейсингу, и
Это всё средства.

P>дает знать команде соответсвующего сервиса, что у них чтото там не то.
А вот и цель. Так чем это принципиально отличается от емейла?

P>·>Я ещё понимаю, если посылать номер версии в хедере "Server" или каком-нибудь "X-My-API-Version". Так консумеры могут догадаться, что с v1.2.3 работало, а с v1.2.4 что-то вдруг подглючивать стало, значит стоит поподробнее changelog почитать. Но что делать с Warning?
P>Например, мониторинг может подсказать, что после передеплоймента какого то из сервисов часть клиенты начали получать варнинги, и это стоит проверить.
Уже поздно. Хотя... если придерживаться принципа "лучше поздно, чем никогда"... то может и ок. Но это как последняя линия обороны.

Здравствуйте, Pauel, Вы писали:

P>l2 смотрят логи и точно так же читают доки.

Т.е предлагается этот хидер писать в логи? Если вызовов 1 млн, то +1 млн записей в лог пока не выкатят релиз с фиксом, верно?

P>>>Что именно ты ждешь? Код, контакт, или запись видео? Внятно вопрос сформулируй.
НС>>Я жду ответа на простой вопрос: "кто будет твой нестандартный хидер читать"?
P>Непосредственно читать-писать будет конкретный пакет, который отвечает за капабилити или продуктовый если его команда решит все вручную пилить.

Ну прочел твой пакет, и? Что он с ним делать то будет?

Здравствуйте, maxkar, Вы писали:

НС>>Это все абстрактно. Давай конкретно. Вот есть некий API. К нему кто то написал клиента и использует в своем софте. Вдруг в хидере начинает приходить сообщение о том, что это API устарело. Кто это сообщение увидит?
M>Клиент и увидит.

Клиент это программа. Толку от того что она что то увидит никакого.

Здравствуйте, ·, Вы писали:

НС>>Это тоже бессмысленно, потому что в нормальном REST url будет вида /api/vXX/collection. И в рамках конкретного vXX никаких ломающих изменений и устаревших API в принципе быть не может.
·>Не может, конечно. Но есть, и будет есть всегда! Баги всё ещё не отменили.

Все равно передавать это в каждом респонсе бессмысленно. Достаточно возвращать это в каком нибудь /status или /health.

Здравствуйте, maxkar, Вы писали:

НС>>И в рамках конкретного vXX никаких ломающих изменений и устаревших API в принципе быть не может.
M>А сколько мы будет этот vXX поддерживать, если у нас уже есть vYY и даже vZZ?

Пока есть ощутимое количество пользователей. А чтобы простимулировать переход — рассылаем им письма. Добавление твоего хидера проблему никак не лечит.

Здравствуйте, maxkar, Вы писали:

M>Если вдруг не заметили — API выдавало предупреждения уже 3 месяца. Вон, в Istio нарисовано же в метриках.

А не проще тогда в лог или метрику сразу писать, а не пересылать зачем то в хидерах клиентам?

Здравствуйте, maxkar, Вы писали:

НС>>В распределенных системах это вряд ли реализуемо, так как упирается в САР-теорему. Максимум можно такое обеспечить для асинхронных операций, и то это будет та еще эквилибристика.
M>А что сложного?



M>Мы уже более-менее согласились на eventual consistency.

Поэтому я и написал про асинхронные вызовы.

M> В рамках eventual consistency уже могут быть различные варианты и техники реализации (те же CRDT-типы в разных вариациях).

И все они сильно сложнее простого синхронного вызова.

M> Ну и вообще, у нас же "Representational State Transfer". У нас операций нет.

Есть. Про verb в HTTP слышал?

M> Мы просто иногда делимся представлением своего локального состояния.

Давай посмотрим на определение, раз уж ты о терминах заговорил:

The term representational state transfer was introduced and defined in 2000 by Roy Fielding in his doctoral dissertation. The term is intended to evoke an image of how a well-designed Web application behaves: it is a network of Web resources (a virtual state machine) where the user advances through the application by selecting links (e.g. http://www.example.com/articles/21), resulting in the next resource's representation (the next application state) being transferred to the client and rendered for the user.

Тут, как видишь, нет ничего про "делимся представлением". Здесь есть про переходы по ссылкам (ака операции), которые приводят к изменению состояния.

M> В этом плане отправка состояния по HTTP мало чем отличается от "асинхронной отправки".

Под асинхронной отправкой я подразумевал менее абстрактные вещи (так то почти все можно асинхронным обозвать). Например когда API использует 202 код, поллинг, хттп-колбеки етц.
С той же оплатой, к примеру — реальные платежные системы, конечно, имеют и синхронное API, и его даже используют. Но при его использовании в 99% случаев начинаются проблемы (лично несколько раз такое лечил в чужих проектах). А нормальный API подразумевает нотификации. Т.е. сервис оплаты по заданному url сам тебя дергает, когда оплата проходит. В промежутке до прихода этой нотификации заказ находится в промежуточном состоянии.
Вот такой подход (та самая eventual consistency) — работает. Но он сильно сложнее по всем параметрам, чем простая синхронная реализация, когда ты просто говоришь POST, а в ответ тебе либо 200, либо ошибка. Поэтому рядом и существует хоть и полурабочее, но простое синхронное апи.

Здравствуйте, ·, Вы писали:

P>>changelog содержит мизерное количество информации — название, ссылка на тикет, подробности, каменты, пул-реквест и тд. Отсюда далеко не всегда ясно, каким именно будет поведение конкретной системы. Соответсвенно, придется 1. прогнать тесты для всех n-систем/сервисов 2. надеяться, что в тестах будет прокрыта именно та самая ветка(и тут надо вспомнить, что не существует таких гарантий).
·>В changelog в любом случае можно поместить несравненно больше информации, чем в хедер.

changelog сам пойдет тестировать задеплоеные сервисы и проверять, покрывают ли тесты все критические места или нет?

P>>Т.е. все равно придется подкрутить мониторинг, что бы он хоть как то детектил проблемы, на случай п.2 А так у нас сразу есть звоночек от мониторинга — на сервисах 0, 8, 124 варнинги, реквест-респонс прилагаются. дальше l2 разбирается, что откуда куда пришло, по трейсингу, и
·>Это всё средства.

Это автоматизируется. А changelog — нет.

P>>дает знать команде соответсвующего сервиса, что у них чтото там не то.
·>А вот и цель. Так чем это принципиально отличается от емейла?

Степенью автоматизации.

P>>Например, мониторинг может подсказать, что после передеплоймента какого то из сервисов часть клиенты начали получать варнинги, и это стоит проверить.
·>Уже поздно. Хотя... если придерживаться принципа "лучше поздно, чем никогда"... то может и ок. Но это как последняя линия обороны.

Неважно, первая или последняя. Закладываться на один только changelog идея так себе — например, некто забыл включить строчку этот changelog. Приплыли.

Здравствуйте, Ночной Смотрящий, Вы писали:

P>>l2 смотрят логи и точно так же читают доки.

НС>Т.е предлагается этот хидер писать в логи? Если вызовов 1 млн, то +1 млн записей в лог пока не выкатят релиз с фиксом, верно?

У нас тысячи сервисов и все используют трейсинг. Соответственно, там и так будет 1млн записей, только +1 строчка в каждой записи. Изменение трафика ничтожное.

НС>>>Я жду ответа на простой вопрос: "кто будет твой нестандартный хидер читать"?
P>>Непосредственно читать-писать будет конкретный пакет, который отвечает за капабилити или продуктовый если его команда решит все вручную пилить.

НС>Ну прочел твой пакет, и? Что он с ним делать то будет?

В соответствии со спекой для капабилити, и конфигом конкретного сервиса. Встроеные [ничего не делать, логировать, нотифицировать, бросить ошибку, вызвать хук], по дефолту — логировать. Каждую капабилити настраивает продуктовый код — "on-warning-header-behavoir":"use-hook"

Здравствуйте, ·, Вы писали:

·>Ну если клиент важный и платит много денег, то можно добиться реакции на письмо. Если на мыло не отвечают совсем, то можно даже позвонить и даже ногами прийти.
Клиент — внутренний и не особо нас любит. Причем не любит "просто-так", а не за то, что и как мы делаем. И вообще он по иерархии того же уровня, что и моя команда. Так что это совсем не моя обязанность в течение трех месяцев уговаривать их перейти на новый API.

M>>API выдавало предупреждения уже 3 месяца. Вон, в Istio нарисовано же в метриках.
·>А это бесмысленная попытка решать административные проблемы техническими средствами.
Почему бессмысленая? Как раз таки очень осмысленная. По результату всех принятых мер я и моя команда находимся в хорошем положении. Если что-то не работает — это не наши проблемы! Этим и достигается цель. Да, я могу выслушать грустную историю. Предложить административные пути. Например, увеличить сроки обратной совместимости (и, соответственно, быть готовым к уменьшению нашей скорости разработки). Или провести лекцию о метриках и мониторинге для той команды, которая три месяца предпочитала ничего не замечать. С техническими средствами я сделал все, что было в моих силах в рамках моей зоны ответственности. А без технических средств я останусь виноватым в недостаточной коммуникации. С учетом того, что я формально разработчик — выбор очевиден.

Здравствуйте, maxkar, Вы писали:

M>Клиент — внутренний и не особо нас любит. Причем не любит "просто-так"


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