Здравствуйте, Pauel, Вы писали:
НС>>В топике зашла речь именно про него. P>Это просто пример кастомного хидера.
Речь шла не про хидеры, а про "Нет в HTTP и API-специфичных вещей".
P> Такие хидеры ни разу не рокетсаенс, и поддерживаются тем же ResponseHeaders в OpenApi
При чем тут ResponseHeaders в OpenApi?
P>>>Зачем пропагейтить? Делегируешь процессинг другому компоненту, он от себя будет кидать, что бы ничего не пропагейтить. НС>>Ничего не понял. P>Ты не в курсе, что такое делегирование и весь код у тебя в контроллерах? Чужой компонент может обрабатывать реквесты от твоего имени, все, что тебе надо — дать конфиг.
Я не понимаю как это все касается темы обсуждения.
НС>>Не надо контролировать все, надо контролировать свой собственный сервис и свои собственные логи, даши и алерты. P>Про делегирование ты не в курсе. Как же ты чужой компонент контролируешь, ы?
Зачем контролировать чужой компонент?
P>>>Варнинг можно интерпретировать мониторингом как на этой стороне, так и на той. НС>>Можно не означает нужно. P>Если это часть апи, то нужно ожидать, что мониторинг на той стороне справится самостоятельно.
Зачем вообще нужен мониторинг на той стороне, если проще на этой?
P>>> И это может быть дешевле чем мастырить архитектуру поверх всего. НС>>Не знаю при чем тут архитектура поверх всего и что ты под ней понимаешь. Но больше на эту роль подходят кастомные хидеры. P>Ты сам привел пример, забыл?
Я окончательно перестал тебя понимать.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[48]: Идемпотентность POST - хорошая ли практика?
Здравствуйте, Pauel, Вы писали:
P>А кто тебе это советует? Это был пример, а не совет.
Это был пример в абсолютно техническом разговоре. Пример проблем стандарта HTTP. А на поверку оказалось, что это был пример административных проблем.
P>Хорошая вещь — например тротлинг сопровождаешь ворнингом.
При чем тут троттлинг?
Основной сценарий — извещать клиента о том, что его запросы перестают соответствовать требованиям и нужно бы что-то сделать. Например, появился новый API, на который нужно перейти.
Не надо мухлевать, вводя новые исходные данные и пристегивая к ним мои ответы.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[54]: Идемпотентность POST - хорошая ли практика?
Здравствуйте, maxkar, Вы писали:
M>Ой! Какой ужас, терабайты! Давайте посчитаем, сколько они стоят. Например, aws ec2 transfer. Самый дорогой — это первые 10Тб, отправленные в интернет. Стоит это 0.09 USD/GB. Т.е. 90 USD/TB. Это где-то 1.5-2 человекочаса. Если вдруг терабайт заголовков позволяет сэкономить 2 часа (суммарно) на координации, переключениях контекста и прочем обслуживании, мы остаемся в плюсе! Данный доступ — это плохое решение. Вместо того, чтобы иметь одну систему мониторинга (для своих сервисов) команда теперь будет вынуждена ходить в несколько различных — свою и каждой зависимости. На ровном месте мы чуть-чуть экономим на заголовках и создаем проблемы администрирования и координации!
Я не понял где и в каком месте произойдёт экономия. Джиры, емейлы, логи, мониторинг и прочее никуда не уходит. Просто появляется ещё дублирование в хедере.
M>Кроме того. Есть еще один замечательный момент. Заголовок с содержимым выглядит примерно так: "X-API-Warnings: W084,W092,W103". Округляя, 100 байт. В килобайте — 10 заголовков. В терабайте 10^10. (мега, гига, тера — 3*3 порядка). Допустим, команда все три месяца ничего не делала и перешла на новый API в последний момент. Т.е. 10^10 ответов было отправлено за 3 месяца. Это дает 10^10 / 3 / 30 / 24 / 60 / 60 = 1286 сообщений в секунду. Что-то мне кажется не очень выгодным тратить время команды, поддерживающей такую нагрузку, на административные задачи и координацию. Я думаю, разработчики будут гораздо более полезны на технических задачах и задачах бизнеса.
Осталось тебе рассказать каким образом хедер будет осуществлять административные задачи и координацию.
M>Что еще. Если у нас терабайты дополнительных заголовков, то логи не работают. Потому что логов тоже терабайты. Ну ладно, по сети они передаются сжатыми. Но обработка и хранение? Я пока не встречал ни одного предложения по обработке логов, где 1ТБ стоил бы всего 90 USD. Так что остаются только метрики. Для этого нам нужно идентифицировать клиентов. Здравствуйте, заголовки.
Это какой сценарий-то? Если не идентифицировать клиентов, то ты не сможешь писать warning-хедер нужным клиентам и не писать ненужным. А warning который пишется всем без разбору не только бесполезен, но даже немножечко вреден.
M> И я уже упоминал сценарий, где несколько deployment unit являются частью одного сервиса и используют одни и те же credentials. Коллега тут предложил использовать "User-Agent". Ну т.е. заголовок. В каждом запросе (API Warnings ходят только там, где есть предупреждения). И по размеру обычно гораздо больше, чем те же коды предупреждений. И кто из нас экономит траффик?
User-Agent это как общее решение. А раз ты как-то ты удосужился узнать где именно это "только там", то и user-agent значит не обязателен.
M>Ну и потом, гоняться по разным Jira и системам за командами — то еще удовольствие.
Хедер вас от этого не избавит.
M>Ведь нужно не только поставить тикет. Нужно, чтобы его заметили нужные люди (я себе настраиваю так, чтобы digest новых тикетов отправлялся на почту каждый день, но далеко не все так делают). Нужно, чтобы не забыли. Особенно если сейчас они заняты другим. А вот постоянно горящая лампочка check engine api usage — хорошая напоминалка. И если команда пользователей делает лампочку сама, с большой вероятностью она окажется на приборной панели (на виду) а не где-нибудь под капотом (там, куда никто из команды не заходит).
Эту лампочку можно зажигать многими другими способами, более надёжными.
Раз вы управляете мониторингом других команд (как-то же вы заставили читать хедер?), то можно сразу сделать рычажок зажечь лампочку напрямую, одной кнопкой, без хедеров в каждом респонзе.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ночной Смотрящий, Вы писали:
P>>А кто тебе это советует? Это был пример, а не совет.
НС>Это был пример в абсолютно техническом разговоре. Пример проблем стандарта HTTP. А на поверку оказалось, что это был пример административных проблем.
Про что было сразу сказано, стоило всего лишь прочесть вводную. Кроме того, ты осознаешь, что это был пример.
P>>Хорошая вещь — например тротлинг сопровождаешь ворнингом.
НС>При чем тут троттлинг?
Еще один пример.
НС>Не надо мухлевать, вводя новые исходные данные и пристегивая к ним мои ответы.
Мухлюешь ты сам, когда пристегиваешь "совет" когда с твоих же слов, сам понимаешь, что был просто пример.
Re[51]: Идемпотентность POST - хорошая ли практика?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>В топике зашла речь именно про него. P>>Это просто пример кастомного хидера.
НС>Речь шла не про хидеры, а про "Нет в HTTP и API-специфичных вещей".
, а именно "а кто их читать будет".
P>> Такие хидеры ни разу не рокетсаенс, и поддерживаются тем же ResponseHeaders в OpenApi
НС>При чем тут ResponseHeaders в OpenApi?
Как я вижу, вытут возбудились именно от кастомности хидера, основная претензия "а кто их читать будет", читай себя же http://rsdn.org/forum/design/8376379.1
P>>Ты не в курсе, что такое делегирование и весь код у тебя в контроллерах? Чужой компонент может обрабатывать реквесты от твоего имени, все, что тебе надо — дать конфиг.
НС>Я не понимаю как это все касается темы обсуждения.
Это еще пример, когда анализ changelog не поможет — надо смотреть зависимости второго уровня. Там часто прячутся просто чудовищные дыры или ломающие изменения.
P>>Про делегирование ты не в курсе. Как же ты чужой компонент контролируешь, ы?
НС>Зачем контролировать чужой компонент?
А он часть твоего сервиса, как я уже показал пример.
P>>Если это часть апи, то нужно ожидать, что мониторинг на той стороне справится самостоятельно.
НС>Зачем вообще нужен мониторинг на той стороне, если проще на этой?
Затем, что они шлют не то и надо бы им сказать. Например продолжают слать по старинке, а в силу фикса зависимости второго уровня надо бы пересмотреть вызывающий код.
НС>>>Не знаю при чем тут архитектура поверх всего и что ты под ней понимаешь. Но больше на эту роль подходят кастомные хидеры. P>>Ты сам привел пример, забыл?
НС>Я окончательно перестал тебя понимать.
Здравствуйте, ·, Вы писали:
P>>Предлагаешь взять до кучи роль топ-менеджера и потратить пять лет на выстраивание процесса коммуникации с консумерами что бы закончить фичу? ·>Без хедера фича не работает?
Нет, не работает. К каждой фиче приклеиваются нефункциональные требования — например, мониторинг на обоих сторонах должен обнаруживать проблемы
·>Итак. Получается такая цепочка: ·>0. Ты обнаружил precondontion. ·>1. Код ворнинга ·>2. QA ·>3. Хедер ·>4. Система логгирования ·>5. Мониторинг ·>6. L2 замечает проблему ·>7. L2 расследует ·>8. разработчик-менеджер.
·>Вот теперь объясни зачем нужны шаги 1-7? Это затраты ресурсов и человеческих, и машинных, и на каждом шаге можно сломаться-потеряться и вся цепочка рухнет. Почему бы сразу не перейти к 8му шагу?
Похоже, тебе религия мешает разобраться, зачем нужны ассерты.
Они нужны в момент, как и логи, во время запуска в тч на проде.
Например — выявить, если какаято из 2^100 комбинаций дала подозрительный результат.
P>>·>У тебя нет 2^100 комбинаций. P>>Есть. Типичный реквест содержит куда больше информации. ·>И что? Мы говорим о конкретном warning, который появится в хедере. Который проверяет вполне конкретную информацию по конкретному алгоритму. Т.е. ровно одна комбинация.
Он проверяет свойство результата, например, или свойство входа. У какой из 2^100 комбинаций эти свойства будут нарушены?
P>>Мы снова говорим о том, что ты не понимаешь роль ассертов. Ассерт используется там, где джира-емейл-тестирование неприменимо. Это механизм того же рода, что и логи. ·>Я о роли ассертов и тестов не рассуждал и вообще ничего не говорил. В данном контексте это неважно.
Наоборот, именно это и важно.
P>>Вот-вот. Ассерты это те же логи, только, только условные. Логи знаешь, а ассерты — нет? ·>И причём тут хедер?
При том, что надо быть дать знать той стороне, что свойства ихнего запроса пудозрительные.
P>>И снова ты пишешь о том, что не в курсе проблемы которую решают ассерты. ·>Мне пофиг какие проблемы решают ассерты. Это к разговору не относится. Я пытаюсь из тебя вытянуть какие проблемы решает хедер.
Ты вроде выяснил — административные, разделяет зоны ответственности."херли вы пользуетесь старой схемой, если год назад мы вам дали новую"
·>Так почему именно хедер с ворнингом надо? Чем другие механизмы не устраивают-то?
Самый простой и дешовый. Другие на порядки дороже.
P>>Тебе все рассказали. Это самый простой способ тригерить сообщения в мониторинг на той стороне. ·>Зачем триггерить мониторинг на той стороне?
Затем, что наши ассерты говорят о том, что у них чего то не то.
P>> у вас там что, секюрити не изобрели? В логах чудовищное количество сенситив инфрмации. Если даешь доступ сотне-тысяче консумеров, это все равно что приговор себе подписать. ·>1. В логах не должно быть сенситив информации. По крайней мере не во всех. На крайний случай заведи лог специально для варнингов и расшарь.
Ога, и так для тыщи консумеров.
·>2. Мы вроде о внутренних консьюмерах говорили.
В данном случае это скорее внешние консумеры. Коммуникация то отсутствует, разные подразделения, может оказаться так, что и доступа друг к другу не имеют вовсе. Т.е. разницы со внешними консумерами никакой. Пока менеджмент не договорится, должно быть решение.
P>>Тебе уже сказали, что все это уже есть. Снова нечитатель? ·>В том-то и дело, что много чего уже есть. Так зачем нужен ещё и хедер?
Здравствуйте, ·, Вы писали:
M>>Что должна делать команда В, которая осознанно использует deprecated API в течение некоторого времени? ·>Договориться с командой A о сроках вывода из эксплуатации.
Каким образом договориться с теми, кто тебя игнорирует? Поделись секретом.
Так часто бывает — только выбрасываешь депрекейтед апи, как тут же находится менеджер, который громогласно заявляет, что в следующем году они планировали на него переходить, а теперь у них тесты красные, верните АПИ, и тд и тд.
При этом
1. changelog есть с начала времен
2. аннотациями размечено, что апи депрекейтед
3. есть страница про end-of-life
4. есть нотификации про релизы и тд.
5. есть родмап
6. есть known issues, how to
7. есть development support, когда можно помочь с миграцией, с добавлением фич, траблшутингом и тд и тд
И тем не менее, вдруг появляется N команд которым позарез нужна пред-пред-предыдущая версия АПИ, потому что у них бюджет-сроки ого-го!
Сколько таких втихую используют старую версию трудно даже посчитать, только по реквестам. Потому имеет смысл доработать респонсы таким образом, что бы люди видели постоянно и непрерывно, что они занимаются хернёй.
Re[52]: Идемпотентность POST - хорошая ли практика?
Здравствуйте, Pauel, Вы писали:
НС>>Речь шла не про хидеры, а про "Нет в HTTP и API-специфичных вещей". P>А можно ссылкой?
Нет в HTTP и API-специфичных вещей. Например, я обычно делаю заголовок X-Api-Warning стандартным в ответах (в значениях — коды, которые можно посмотреть в документации по конкретному сервису). Основной сценарий — извещать клиента о том, что его запросы перестают соответствовать требованиям и нужно бы что-то сделать. Например, появился новый API, на который нужно перейти.
P>>> Такие хидеры ни разу не рокетсаенс, и поддерживаются тем же ResponseHeaders в OpenApi НС>>При чем тут ResponseHeaders в OpenApi? P>Как я вижу, вытут возбудились именно от кастомности хидера
Нет.
P>>>Ты не в курсе, что такое делегирование и весь код у тебя в контроллерах? Чужой компонент может обрабатывать реквесты от твоего имени, все, что тебе надо — дать конфиг. НС>>Я не понимаю как это все касается темы обсуждения. P>Это еще пример, когда анализ changelog не поможет — надо смотреть зависимости второго уровня.
Все равно непонятно.
P>>>Про делегирование ты не в курсе. Как же ты чужой компонент контролируешь, ы? НС>>Зачем контролировать чужой компонент? P>А он часть твоего сервиса, как я уже показал пример.
Я не понимаю какое отношение к передаче чего то между сервисами имеют внутрисервисные компоненты. Разговаривали про коммуникацию между сервисами, логично было предположить что речь шла про зависимости между сервисами. И ту, внезапно, ты пишешь про какие то внутренние зависимости.
P>>>Если это часть апи, то нужно ожидать, что мониторинг на той стороне справится самостоятельно. НС>>Зачем вообще нужен мониторинг на той стороне, если проще на этой? P>Затем, что они шлют не то и надо бы им сказать.
И почему выбран именно вариант с пересылкой чего то в хидере в каждом респонсе, если есть масса других способов, не нагружающих продовый протокол?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[53]: Идемпотентность POST - хорошая ли практика?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Речь шла не про хидеры, а про "Нет в HTTP и API-специфичных вещей". P>>А можно ссылкой?
НС>
НС>Нет в HTTP и API-специфичных вещей. Например, я обычно делаю заголовок X-Api-Warning стандартным в ответах (в значениях — коды, которые можно посмотреть в документации по конкретному сервису). Основной сценарий — извещать клиента о том, что его запросы перестают соответствовать требованиям и нужно бы что-то сделать. Например, появился новый API, на который нужно перейти.
P>>>>Ты не в курсе, что такое делегирование и весь код у тебя в контроллерах? Чужой компонент может обрабатывать реквесты от твоего имени, все, что тебе надо — дать конфиг. НС>>>Я не понимаю как это все касается темы обсуждения. P>>Это еще пример, когда анализ changelog не поможет — надо смотреть зависимости второго уровня.
НС>Все равно непонятно.
Что тут непонятного? Компонент — часть твоего сервиса, и сам обрабатывает http-трафик, откуда ясно, что ничего пропагейтить не надо. Теперь одна из зависимостей этого компонента вдруг чего то там поменяла. Как ты это обнаружишь, если не собираешься читать changlelog зависимостей 2го уровня?
НС>Я не понимаю какое отношение к передаче чего то между сервисами имеют внутрисервисные компоненты. Разговаривали про коммуникацию между сервисами, логично было предположить что речь шла про зависимости между сервисами. И ту, внезапно, ты пишешь про какие то внутренние зависимости.
Я пишу про зависимости второго уровня. Ты же собирался changelog читатать и предложил это как решение.
НС>>>Зачем вообще нужен мониторинг на той стороне, если проще на этой? P>>Затем, что они шлют не то и надо бы им сказать. НС>И почему выбран именно вариант с пересылкой чего то в хидере в каждом респонсе, если есть масса других способов, не нагружающих продовый протокол?
Потому, что это проще и дешевле. Нагрузка на транспорт ничтожная. А твое предложение — поднять, как вариант, редис, подразумевает, что и платить за этот редис и прочие сопутствующие вещи. "Такие вещи, как я уже сказал, обычно делаются при помощи CR и оператора (либо, если нужна супероперативность, с каким нибудь промежуточным хранилищем типа редиса или консула), "
Более того — запрос к редису всё равно придется делать. Т.е. вместо строчки варнинга, условно, 100 байт максимум, у тебя будет запрос в редис, как минимум. С т.з. разработки нам надо теперь протестировать, что наша апликачка не просто возвращает чего то там, а еще и правильно взаимодействует с редисом, и этот редис надо теперь таскать во все деплойменты.
Далее, редисом дело не ограничивается, это все надо по любому вывести в мониторинг.
Итого — если можно решить черз АПИ, стоит начать именно с этого.
Re[56]: Идемпотентность POST - хорошая ли практика?
Здравствуйте, Pauel, Вы писали:
P>Похоже, тебе религия мешает разобраться, зачем нужны ассерты.
Ассерты тут вообще непричём. Я пытаюсь разобраться зачем нужен этот хедер. Но ты всё время куда-то в сторону уводишь разговор.
P>Они нужны в момент, как и логи, во время запуска в тч на проде. P>Например — выявить, если какаято из 2^100 комбинаций дала подозрительный результат.
Выявлять комбинации ассерты не могут в принципе. Ассерт может лишь выявить комбинацию, прописанную в precondition. Или у тебя в коде 2^100 ассертов?!
P>>>·>У тебя нет 2^100 комбинаций. P>>>Есть. Типичный реквест содержит куда больше информации. P>·>И что? Мы говорим о конкретном warning, который появится в хедере. Который проверяет вполне конкретную информацию по конкретному алгоритму. Т.е. ровно одна комбинация. P>Он проверяет свойство результата, например, или свойство входа. У какой из 2^100 комбинаций эти свойства будут нарушены?
У той, которая прописана в precondition.
P>>>Мы снова говорим о том, что ты не понимаешь роль ассертов. Ассерт используется там, где джира-емейл-тестирование неприменимо. Это механизм того же рода, что и логи. P>·>Я о роли ассертов и тестов не рассуждал и вообще ничего не говорил. В данном контексте это неважно. P>Наоборот, именно это и важно.
Важно для чего? Вопрос был — почему ассерт должен добавлять именно хедер?
P>>>Вот-вот. Ассерты это те же логи, только, только условные. Логи знаешь, а ассерты — нет? P>·>И причём тут хедер? P>При том, что надо быть дать знать той стороне, что свойства ихнего запроса пудозрительные.
Почему это надо сделать именно хедером?
P>>>И снова ты пишешь о том, что не в курсе проблемы которую решают ассерты. P>·>Мне пофиг какие проблемы решают ассерты. Это к разговору не относится. Я пытаюсь из тебя вытянуть какие проблемы решает хедер. P>Ты вроде выяснил — административные, разделяет зоны ответственности."херли вы пользуетесь старой схемой, если год назад мы вам дали новую"
Мы вроде выяснили, что хедер никак не может решать административные проблемы. Игнорировать хедеры гораздо проще, чем, например, емейлы и т.п.
P>·>Так почему именно хедер с ворнингом надо? Чем другие механизмы не устраивают-то? P>Самый простой и дешовый. Другие на порядки дороже.
За счёт чего? Как выяснили выше, хедер добавляет 7 лишних шагов, приводя к тому же результату. Лишние шаги лишь добавляют к стоимости. Неясно на чём они экономят. В конце цепочки всё равно будет емейл разработчику-менеджеру.
P>>>Тебе все рассказали. Это самый простой способ тригерить сообщения в мониторинг на той стороне. P>·>Зачем триггерить мониторинг на той стороне? P>Затем, что наши ассерты говорят о том, что у них чего то не то.
Пусть ваши ассерты хоть свежие анекдоты рассказывают. Так с какой целью вам нужно триггерить мониторинг на той стороне?
P>>> у вас там что, секюрити не изобрели? В логах чудовищное количество сенситив инфрмации. Если даешь доступ сотне-тысяче консумеров, это все равно что приговор себе подписать. P>·>1. В логах не должно быть сенситив информации. По крайней мере не во всех. На крайний случай заведи лог специально для варнингов и расшарь. P>Ога, и так для тыщи консумеров.
Ты вначале расскажи, как ты будешь контролировать что делает мониторинг у тыщи консьюмеров.
P>·>2. Мы вроде о внутренних консьюмерах говорили. P>В данном случае это скорее внешние консумеры. Коммуникация то отсутствует, разные подразделения, может оказаться так, что и доступа друг к другу не имеют вовсе. Т.е. разницы со внешними консумерами никакой. Пока менеджмент не договорится, должно быть решение.
Значит и их мониторинг вам неподконтролен. И какие-то из 1-7 шагов будут благополучно потеряны и забыты практически наверняка.
P>>>Тебе уже сказали, что все это уже есть. Снова нечитатель? P>·>В том-то и дело, что много чего уже есть. Так зачем нужен ещё и хедер? P>Что бы мониторинг на той стороне сработал.
Где гарантия, что он сработает? Где гарантия, что он не будет проигнорирован? Почему не подходят многие другие способы коммуникации?
Здравствуйте, Pauel, Вы писали:
M>>>Что должна делать команда В, которая осознанно использует deprecated API в течение некоторого времени? P>·>Договориться с командой A о сроках вывода из эксплуатации. P>Каким образом договориться с теми, кто тебя игнорирует? Поделись секретом.
Escalate.
P>Так часто бывает — только выбрасываешь депрекейтед апи, как тут же находится менеджер, который громогласно заявляет, что в следующем году они планировали на него переходить, а теперь у них тесты красные, верните АПИ, и тд и тд. P>И тем не менее, вдруг появляется N команд которым позарез нужна пред-пред-предыдущая версия АПИ, потому что у них бюджет-сроки ого-го!
Допустим. И хедер, значит вдруг все бюджет со сроками поменяет?
P>Сколько таких втихую используют старую версию трудно даже посчитать, только по реквестам.
И тут у вас Хедер на Белом коне, всю херню повергнет и менеджеров в бегство обратит. Я правильно понял?
P>Потому имеет смысл доработать респонсы таким образом, что бы люди видели постоянно и непрерывно, что они занимаются хернёй.
Открою для тебя секрет — не у всех людей есть хобби рассматривать хедеры респонзов.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[55]: Идемпотентность POST - хорошая ли практика?
Здравствуйте, ·, Вы писали:
P>>·>Договориться с командой A о сроках вывода из эксплуатации. P>>Каким образом договориться с теми, кто тебя игнорирует? Поделись секретом. ·>Escalate.
Когда ворнинг попал в АПИ, то это значит, что всё уже было много раз. Может даже архитектор пришел и сказал — делаем так, потому что мне приказали.
P>>И тем не менее, вдруг появляется N команд которым позарез нужна пред-пред-предыдущая версия АПИ, потому что у них бюджет-сроки ого-го! ·>Допустим. И хедер, значит вдруг все бюджет со сроками поменяет?
Хидер это часть апи. И самое меньшее, что можно ожидать, сообщения в тамошнем мониторинге. И когда будут претензии, они будут, т.к. есть сложности с коммуникацией, то будет ответ — "а чой та вы свой мониторинг игнорируете?"
P>>Сколько таких втихую используют старую версию трудно даже посчитать, только по реквестам. ·>И тут у вас Хедер на Белом коне, всю херню повергнет и менеджеров в бегство обратит. Я правильно понял?
Тебе снова повторить про l2 суппорт, мониторинг на той стороне, специализированый клиент?
Кроме того, если ты вкоммитал поддержку апи, то дальше это твои и твоего подразделения проблемы, что вы там чего то игнорируете.
P>>Потому имеет смысл доработать респонсы таким образом, что бы люди видели постоянно и непрерывно, что они занимаются хернёй. ·>Открою для тебя секрет — не у всех людей есть хобби рассматривать хедеры респонзов.
У людей — нет, а вот у клиента, который поддерживает это апи, и l2 суппорта, будет все необходимое. Первый под это заточен, а у вторых работа такая.
Если игнорируют и девелопервы, и l2 суппорт, опять же, это проблемы вашего подразделения, что вы не смотрите в апи, которое вызываете.
Re[57]: Идемпотентность POST - хорошая ли практика?
Здравствуйте, ·, Вы писали:
P>>Похоже, тебе религия мешает разобраться, зачем нужны ассерты. ·>Ассерты тут вообще непричём. Я пытаюсь разобраться зачем нужен этот хедер. Но ты всё время куда-то в сторону уводишь разговор.
Тебе уже много раз рассказали.
P>>Они нужны в момент, как и логи, во время запуска в тч на проде. P>>Например — выявить, если какаято из 2^100 комбинаций дала подозрительный результат. ·>Выявлять комбинации ассерты не могут в принципе. Ассерт может лишь выявить комбинацию, прописанную в precondition. Или у тебя в коде 2^100 ассертов?!
Могут, еще как. Это их основное предназначение. Сам же пишешь — выявить комбинацию прописаную в условии. Только не precondition, а postcondintion, и даже инвариант. И не сама комбинация прописывает, а её признаки. Условие ровно одно — свойства входа или результата. Например — контрольная сумма. Гыгы. Не сходится — с реквестом вероятно чтото не то. Логируем, выставляем варнинг и возвращаем респонс.
P>>Он проверяет свойство результата, например, или свойство входа. У какой из 2^100 комбинаций эти свойства будут нарушены? ·>У той, которая прописана в precondition.
В прекондишн прописано только условие. На этапе разработки ты эту комбинацию не знаешь.
P>>Наоборот, именно это и важно. ·>Важно для чего? Вопрос был — почему ассерт должен добавлять именно хедер?
Надо же как то задетектить некорректный вызов. Есть простой вариант — deprecated вызов. Если все сходится к этому — это очень даже легко. Есть и более сложные, например, процессинг выдал варнинги, которых быть не должно, и в хидере x-варнинг будет ссылка на урл этих варнингов.
P>>При том, что надо быть дать знать той стороне, что свойства ихнего запроса пудозрительные. ·>Почему это надо сделать именно хедером?
Например, потому что это самый простой и дешевый способ разграничить ответственность. Вкомитал вызов согласно этому АПИ — теперь отвечай сам за корректность запросов.
P>>Ты вроде выяснил — административные, разделяет зоны ответственности."херли вы пользуетесь старой схемой, если год назад мы вам дали новую" ·>Мы вроде выяснили, что хедер никак не может решать административные проблемы. Игнорировать хедеры гораздо проще, чем, например, емейлы и т.п.
Ага, в ответ на "escalate" прибегает архитектор, и говорит "делай хидер с варнингом, мне так приказали сверху, теперь всё апи будет таким."
·>За счёт чего? Как выяснили выше, хедер добавляет 7 лишних шагов, приводя к тому же результату. Лишние шаги лишь добавляют к стоимости. Неясно на чём они экономят. В конце цепочки всё равно будет емейл разработчику-менеджеру.
Ты так и не рассказал, как будет без хидера
P>>Затем, что наши ассерты говорят о том, что у них чего то не то. ·>Пусть ваши ассерты хоть свежие анекдоты рассказывают. Так с какой целью вам нужно триггерить мониторинг на той стороне?
Что бы они приняли действия на своей стороне по исправлению проблемы.
P>>Ога, и так для тыщи консумеров. ·>Ты вначале расскажи, как ты будешь контролировать что делает мониторинг у тыщи консьюмеров.
В том то и дело, что мне и не надо это делать. Как только они вкомитали использование этого апи, теперь это их забота. Я могу гайдлайны подкинуть, типа "добавьте правило в мониторинг". Но контролировать свою сторону будут они сами.
P>>В данном случае это скорее внешние консумеры. Коммуникация то отсутствует, разные подразделения, может оказаться так, что и доступа друг к другу не имеют вовсе. Т.е. разницы со внешними консумерами никакой. Пока менеджмент не договорится, должно быть решение. ·>Значит и их мониторинг вам неподконтролен. И какие-то из 1-7 шагов будут благополучно потеряны и забыты практически наверняка.
Забавно, что ты так и не показал, что будет в твоем случае. В основном эти 1-7 шагов благополучно работают, и именно потому, что легко автоматизируются и не требуют давать взятку менеджеру по security.
P>>Что бы мониторинг на той стороне сработал. ·>Где гарантия, что он сработает? Где гарантия, что он не будет проигнорирован? Почему не подходят многие другие способы коммуникации?
Эти гарантии пусть они сами обеспечивают. Почему не подходят другие способы коммуникации — вот бы узнать, почему ихние менеджеры игнорируют емейлы.
Вот пример — в марте один заказал большую фичу, запили, в июне написал ему сообщение, что де фича готова, пользуйтесь и тд и тд.
И в начале октября он начал задавать вопросы, о чем это я
Зато при траблшутниге, если их L2 суппорт придет ко мне, мне достаточно кидануть им одну ссылку, что бы они были в курсе, как починить.
·>Прикольно, оказывается в http есть хедер Warning. И, кто бы мог подумать, deprectated.
Для браузера в этом смысла не много, он всё равно ничего исправить не сможет. А вот в конкретном приложении на такой хидер можно навесить дополнительные капабилити, например, счетчик варнингов и тротлинг по мере роста, логирование на вызывающей стороне, И это всё без изменения кода сервисов.
Здравствуйте, Pauel, Вы писали:
НС>>Это был пример в абсолютно техническом разговоре. Пример проблем стандарта HTTP. А на поверку оказалось, что это был пример административных проблем. P>Про что было сразу сказано, стоило всего лишь прочесть вводную.
Где про это было сказано?
P>>>Хорошая вещь — например тротлинг сопровождаешь ворнингом. НС>>При чем тут троттлинг? P>Еще один пример.
Пример чего?
НС>>Не надо мухлевать, вводя новые исходные данные и пристегивая к ним мои ответы. P>Мухлюешь ты сам, когда пристегиваешь "совет" когда с твоих же слов, сам понимаешь, что был просто пример.
Ничего не понял. Какой совет, куда я его пристегнул?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[51]: Идемпотентность POST - хорошая ли практика?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Это был пример в абсолютно техническом разговоре. Пример проблем стандарта HTTP. А на поверку оказалось, что это был пример административных проблем. P>>Про что было сразу сказано, стоило всего лишь прочесть вводную.
НС>Где про это было сказано?
Собственно, после этих утверждений никаких сомнений быть не может
НС>>>При чем тут троттлинг? P>>Еще один пример.
НС>Пример чего?
Еще пример, что бы яснее было. Как только появляется фича в апи, в т.ч. хидер x-варнинг, у нас искаропки есть капабилити благодаря мониторингу, апи гатевею, итд итд.
НС>>>Не надо мухлевать, вводя новые исходные данные и пристегивая к ним мои ответы. P>>Мухлюешь ты сам, когда пристегиваешь "совет" когда с твоих же слов, сам понимаешь, что был просто пример.
НС>Ничего не понял. Какой совет, куда я его пристегнул?
мы видим здесь, что тебе мерещится совет.
И тут же пишешь "Это был пример в абсолютно техническом разговоре. " То есть, ты в курсе, что это был не совет, а пример.
Ну и если отмотать на начало, то самое, что ты сам указал, видим " Например, я обычно делаю заголовок X-Api-Warning стандартным в ответах..."
Вроде бы понятно, что здесь написано "Например", а не "мой совет — делать так"
Re[56]: Идемпотентность POST - хорошая ли практика?
Здравствуйте, Pauel, Вы писали:
P>>>Каким образом договориться с теми, кто тебя игнорирует? Поделись секретом. P>·>Escalate. P>Когда ворнинг попал в АПИ, то это значит, что всё уже было много раз. Может даже архитектор пришел и сказал — делаем так, потому что мне приказали.
Что магического в варнинге такого, что его не игнорируют, а всё остальное игнорируют?
P>>>И тем не менее, вдруг появляется N команд которым позарез нужна пред-пред-предыдущая версия АПИ, потому что у них бюджет-сроки ого-го! P>·>Допустим. И хедер, значит вдруг все бюджет со сроками поменяет? P>Хидер это часть апи. И самое меньшее, что можно ожидать, сообщения в тамошнем мониторинге. И когда будут претензии, они будут, т.к. есть сложности с коммуникацией, то будет ответ — "а чой та вы свой мониторинг игнорируете?"
Чем игнорирование мониторинга принципиально отличается от игнорирования, например, емейлов?
Единственный ответ напрашивается: у вас так принято, у вас вокруг этого уже есть построенная инфраструктура и культура коммуникации. Ну ради бога. Хоть хедеры шлите, хоть в бубен бейте и дымовые сигналы подавайте. Но рекомендовать такое — не надо, это не самое эффективное решение.
P>>>Сколько таких втихую используют старую версию трудно даже посчитать, только по реквестам. P>·>И тут у вас Хедер на Белом коне, всю херню повергнет и менеджеров в бегство обратит. Я правильно понял? P>Тебе снова повторить про l2 суппорт, мониторинг на той стороне, специализированый клиент?
Повторять не надо. Нужно объяснить, почему прямой емейл не работает, а емейл посланный от l2 через несколько слоёв — работает?
P>Кроме того, если ты вкоммитал поддержку апи, то дальше это твои и твоего подразделения проблемы, что вы там чего то игнорируете.
У нас обычно взаимодействующие системы обмениваются Point of Contact — для AppDevs (для вопросов разработки) и для ProdSupport (для вопросов экспуатации). Это просто email-рассылки. Ибо это проблема организационная и административная.
P>>>Потому имеет смысл доработать респонсы таким образом, что бы люди видели постоянно и непрерывно, что они занимаются хернёй. P>·>Открою для тебя секрет — не у всех людей есть хобби рассматривать хедеры респонзов. P>У людей — нет, а вот у клиента, который поддерживает это апи, и l2 суппорта, будет все необходимое. Первый под это заточен, а у вторых работа такая.
l2 суппорт это не люди что-ли?! В данном случае API может лишь переслать сообщения между людьми, и ничего более. Вот и неясно чем smtp хуже, чем http.
P>Если игнорируют и девелопервы, и l2 суппорт, опять же, это проблемы вашего подразделения, что вы не смотрите в апи, которое вызываете.
Значит должны общаться люди, а не приложения. Вот и неясно, чем же вы обосновываете необходимость общения людей через _Application_ Programming Interface.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[57]: Идемпотентность POST - хорошая ли практика?
Здравствуйте, ·, Вы писали:
P>>Когда ворнинг попал в АПИ, то это значит, что всё уже было много раз. Может даже архитектор пришел и сказал — делаем так, потому что мне приказали. ·>Что магического в варнинге такого, что его не игнорируют, а всё остальное игнорируют?
Никакая это не магия — это часть АПИ. Потому искаропки доступны капабилити апи гатевей, мониторинга и тд, даже если письма никто не читает.
P>>Хидер это часть апи. И самое меньшее, что можно ожидать, сообщения в тамошнем мониторинге. И когда будут претензии, они будут, т.к. есть сложности с коммуникацией, то будет ответ — "а чой та вы свой мониторинг игнорируете?" ·>Чем игнорирование мониторинга принципиально отличается от игнорирования, например, емейлов?
Игнорируют в основном не специально, а в силу перегрузки. Емейл — крайне перегруженый канал в корпорациях. Мониторинг изначально строится так, что бы можно было легко отслеживать проблемы в работающих сервисах.
Емейл может затеряться, changelog может содержать не всю информацию или не содержать вовсе, депенденсы 2го уровня могут измениться в ряде случаев — ситуаций слишком много.
А вот мониторинг и апи гатевей это одни из надежных механизмов, на которые и стоит полагаться.
·>Единственный ответ напрашивается: у вас так принято, у вас вокруг этого уже есть построенная инфраструктура и культура коммуникации. Ну ради бога. Хоть хедеры шлите, хоть в бубен бейте и дымовые сигналы подавайте. Но рекомендовать такое — не надо, это не самое эффективное решение.
Ты эффективного пока не показал. Кроме того, здесь буквально примеры, а не советы.
P>>Тебе снова повторить про l2 суппорт, мониторинг на той стороне, специализированый клиент? ·>Повторять не надо. Нужно объяснить, почему прямой емейл не работает, а емейл посланный от l2 через несколько слоёв — работает?
L2 суппорт может и по телефону набрать, когда есть на то необходимость. Они не связаны инструкциями, как L1, потому могут много чего. Не отвечает один менеджер — найдут другого, не отвечает и этот — смогут изыскать QA, девелопера и тд.
Потому и работает, что нет привязки к какому либо каналу информации вроде перегруженного емейла.
·>У нас обычно взаимодействующие системы обмениваются Point of Contact — для AppDevs (для вопросов разработки) и для ProdSupport (для вопросов экспуатации). Это просто email-рассылки. Ибо это проблема организационная и административная.
Этого мало. Для начала, ктото должен читать это всё, предпринимать действия и тд и тд.
P>>У людей — нет, а вот у клиента, который поддерживает это апи, и l2 суппорта, будет все необходимое. Первый под это заточен, а у вторых работа такая. ·>l2 суппорт это не люди что-ли?! В данном случае API может лишь переслать сообщения между людьми, и ничего более. Вот и неясно чем smtp хуже, чем http.
Потому, как почта почти всегда перегружена, и её большей частью читают не в режиме реального времени, а когда найдется время. И то читают не всё.
Если выбираем вариант с АПИ, то мы полагаемся на тот факт, что у вызывающей стороны есть команда эксплуатации, и что они будут делом заняты, а не бамбук курить.
Как они связаны с менеджерами — обычно целой кучей способов, включая телефонный звонок.
P>>Если игнорируют и девелопервы, и l2 суппорт, опять же, это проблемы вашего подразделения, что вы не смотрите в апи, которое вызываете. ·>Значит должны общаться люди, а не приложения. Вот и неясно, чем же вы обосновываете необходимость общения людей через _Application_ Programming Interface.
Эту необходимость обосновывает менеджмент когда не может навести порядок, а я просто пересказываю. Нету обоснований — говорю, что не в курсе почему, но работает так то и так то.
Re[58]: Идемпотентность POST - хорошая ли практика?
Здравствуйте, Pauel, Вы писали:
P>>>Похоже, тебе религия мешает разобраться, зачем нужны ассерты. P>·>Ассерты тут вообще непричём. Я пытаюсь разобраться зачем нужен этот хедер. Но ты всё время куда-то в сторону уводишь разговор. P>Тебе уже много раз рассказали.
Рассказано текущее положение дел у вас, а не обоснование чем такое решение лучше, чем альтернативы.
P>>>Они нужны в момент, как и логи, во время запуска в тч на проде. P>>>Например — выявить, если какаято из 2^100 комбинаций дала подозрительный результат. P>·>Выявлять комбинации ассерты не могут в принципе. Ассерт может лишь выявить комбинацию, прописанную в precondition. Или у тебя в коде 2^100 ассертов?! P>Могут, еще как. Это их основное предназначение. Сам же пишешь — выявить комбинацию прописаную в условии. Только не precondition, а postcondintion, и даже инвариант. И не сама комбинация прописывает, а её признаки. Условие ровно одно — свойства входа или результата.
Под precondition я имею в виду идентификатор из твоего кода: Warning.assert(precondontion, 'unexpected input'). Тебя опять куда-то унесло в оффтопик.
P>Например — контрольная сумма. Гыгы. Не сходится — с реквестом вероятно чтото не то. Логируем, выставляем варнинг и возвращаем респонс.
Такую херню надо просто реджектить без вопросов. Если вы не реджектите, то ясно понятно почему у вас такая беда с тестированием и контролем качества. Системы как бы работают, но никто толком не понимает как и почему.
P>>>Он проверяет свойство результата, например, или свойство входа. У какой из 2^100 комбинаций эти свойства будут нарушены? P>·>У той, которая прописана в precondition. P>В прекондишн прописано только условие. На этапе разработки ты эту комбинацию не знаешь.
Если ты эту комбинацию не знаешь, ты не сможешь написать Warning.assert(precondontion, 'unexpected input').
P>>>Наоборот, именно это и важно. P>·>Важно для чего? Вопрос был — почему ассерт должен добавлять именно хедер? P>Надо же как то задетектить некорректный вызов. Есть простой вариант — deprecated вызов. Если все сходится к этому — это очень даже легко. Есть и более сложные, например, процессинг выдал варнинги, которых быть не должно, и в хидере x-варнинг будет ссылка на урл этих варнингов.
Перечитай вопрос внимательно. Почему именно хедер? Например, пусть ваш мониторинг аггрится на ERROR в логах и шлёт емейлы кому положено, напрямую. Зачем эти промежуточные слои через rest, чужой мониторинг, чужой L2 и т.п.?
P>>>При том, что надо быть дать знать той стороне, что свойства ихнего запроса пудозрительные. P>·>Почему это надо сделать именно хедером? P>Например, потому что это самый простой и дешевый способ разграничить ответственность. Вкомитал вызов согласно этому АПИ — теперь отвечай сам за корректность запросов.
Некорректные запросы надо просто реджектить. Давай другой пример.
P>>>Ты вроде выяснил — административные, разделяет зоны ответственности."херли вы пользуетесь старой схемой, если год назад мы вам дали новую" P>·>Мы вроде выяснили, что хедер никак не может решать административные проблемы. Игнорировать хедеры гораздо проще, чем, например, емейлы и т.п. P>Ага, в ответ на "escalate" прибегает архитектор, и говорит "делай хидер с варнингом, мне так приказали сверху, теперь всё апи будет таким."
Т.е. у вас так принято, культ карго. Так бы сразу и сказал.
P>·>За счёт чего? Как выяснили выше, хедер добавляет 7 лишних шагов, приводя к тому же результату. Лишние шаги лишь добавляют к стоимости. Неясно на чём они экономят. В конце цепочки всё равно будет емейл разработчику-менеджеру. P>Ты так и не рассказал, как будет без хидера
Сказал. После 0го шага идёт сразу 8й.
P>>>Затем, что наши ассерты говорят о том, что у них чего то не то. P>·>Пусть ваши ассерты хоть свежие анекдоты рассказывают. Так с какой целью вам нужно триггерить мониторинг на той стороне? P>Что бы они приняли действия на своей стороне по исправлению проблемы.
Как это их обязует принимать действия? Почему они не могут предпринять те же действия, например, при получении емейла от вас?
P>>>Ога, и так для тыщи консумеров. P>·>Ты вначале расскажи, как ты будешь контролировать что делает мониторинг у тыщи консьюмеров. P>В том то и дело, что мне и не надо это делать. Как только они вкомитали использование этого апи, теперь это их забота. Я могу гайдлайны подкинуть, типа "добавьте правило в мониторинг". Но контролировать свою сторону будут они сами.
Так чтение емейлов тоже их забота. В чём разница?
P>>>В данном случае это скорее внешние консумеры. Коммуникация то отсутствует, разные подразделения, может оказаться так, что и доступа друг к другу не имеют вовсе. Т.е. разницы со внешними консумерами никакой. Пока менеджмент не договорится, должно быть решение. P>·>Значит и их мониторинг вам неподконтролен. И какие-то из 1-7 шагов будут благополучно потеряны и забыты практически наверняка. P>Забавно, что ты так и не показал, что будет в твоем случае. В основном эти 1-7 шагов благополучно работают, и именно потому, что легко автоматизируются и не требуют давать взятку менеджеру по security.
Да тоже самое. Оптимум — после 0го шага сразу 8й. Ну или 7й, может быть. Шаги 1-6 не нужны вообще.
P>>>Что бы мониторинг на той стороне сработал. P>·>Где гарантия, что он сработает? Где гарантия, что он не будет проигнорирован? Почему не подходят многие другие способы коммуникации? P>Эти гарантии пусть они сами обеспечивают. Почему не подходят другие способы коммуникации — вот бы узнать, почему ихние менеджеры игнорируют емейлы.
Если они могут обеспечить, что ихние менеджеры не игнорируют емейлы от L2, то они смогут обеспечить, чтобы ихние менеджеры не игнорировали емейлы от вас. А если нет, то и хедеры не помогут. Вывод — хедер — лишняя сущность.
Вообще говоря, если эта проблема дошла до L2, т.е. прод-суппорт, это уже большой организационный фейл. Такие вещи должны утрясываться между AD.
P>Вот пример — в марте один заказал большую фичу, запили, в июне написал ему сообщение, что де фича готова, пользуйтесь и тд и тд. P>И в начале октября он начал задавать вопросы, о чем это я P>Зато при траблшутниге, если их L2 суппорт придет ко мне, мне достаточно кидануть им одну ссылку, что бы они были в курсе, как починить.
Придёт так же в октябре. В чём разница-то?
P>·>Прикольно, оказывается в http есть хедер Warning. И, кто бы мог подумать, deprectated. P>Для браузера в этом смысла не много, он всё равно ничего исправить не сможет. А вот в конкретном приложении на такой хидер можно навесить дополнительные капабилити, например, счетчик варнингов и тротлинг по мере роста, логирование на вызывающей стороне, И это всё без изменения кода сервисов.
Для этого не нужен хедер отправлять консьюмерам. Т.к. это всё навешивается у провайдера, а не у консьюмеров. Опять на ходу тему меняешь.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[55]: Идемпотентность POST - хорошая ли практика?
Здравствуйте, ·, Вы писали:
·>Если не идентифицировать клиентов, то ты не сможешь писать warning-хедер нужным клиентам и не писать ненужным.
А зачем мне идентифицировать клиентов для простановки заголовка? Какая разница, Петя вызывает deprecated API или Вася? Warning будет отправлен ровно тем (и всем тем) клиентам, которые этот deprecated API используют. А тем, кто его не использует — отправлены не будут. Здесь все зависит в первую очередь от самого API. Может иногда от того, что содержится в запросе. А вот от имени пользователя, клиентской библиотеки и того, где и как клиент крутится — не зависит.
Re[56]: Идемпотентность POST - хорошая ли практика?
Здравствуйте, maxkar, Вы писали:
M>·>Если не идентифицировать клиентов, то ты не сможешь писать warning-хедер нужным клиентам и не писать ненужным. M>А зачем мне идентифицировать клиентов для простановки заголовка? Какая разница, Петя вызывает deprecated API или Вася? Warning будет отправлен ровно тем (и всем тем) клиентам, которые этот deprecated API используют. А тем, кто его не использует — отправлены не будут. Здесь все зависит в первую очередь от самого API. Может иногда от того, что содержится в запросе. А вот от имени пользователя, клиентской библиотеки и того, где и как клиент крутится — не зависит.
Ты же как-то узнаёшь, что используется именно deprecated api... Получается т.е. ты идентифицируешь deprecated клиентов по урлу или как-то иначе, а не user-agent... суть та же.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
у вас там что, секюрити не изобрели? В логах чудовищное количество сенситив инфрмации. Если даешь доступ сотне-тысяче консумеров, это все равно что приговор себе подписать.
