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

S>·>Других вариантов нет, если нужна надёжная система.
S>·>Хедер не поможет.
S>Ну, если его нет — то да, не поможет.
S>Непонятно, чем будет плохо, если он есть.
Затем, что это дополнительная функциональность, которую надо проектировать, документировать, тестировать, мейнтейнить и т.п. Плюс риск чего-нибудь поломать. Заспамить нечаяно мониторинг у кого-нибудь, например.

S>·>Я не сказал, что для каждого API должна быть отдельная персональная команда. Я сказал, что за анонсами каждого API должна следить команда.
S>Вы сказали, что на каждый канал — по одной команде.
S>Я это интерпретирую так, что за анонсами PC API Microsoft (публикуются на специальной страничке под авторизацией) следит одна команда.
S>За анонсами S3 API Amazon — другая команда. И так далее.
Э, нет, конечно, да и зачем? Может я оговорился где-то, но не имел в виду такое.

S>·>Это может быть одна команда, которая следит за всеми API.
S>·>Например, на одной из прошлых работ у была Market Connectivity team. Которая отвечала за всю ~сотню бирж. И там не только deprecated api (куда кстати, хедер пихать в какой-нибудь FIX — неясно), но и всякие аннонсы изменений в opening hours, holidays, data centre relocations, изменения в требованиях аудита, routing rules, переключения между dr/prd и т.д., т.п.
S>Интересно, сколько было народу в этой команде.
Не помню, порядка 5 человек, вроде, в разных таймзонах чтобы. По сути работа не сложная, но нудная... разгребать письма, поддерживать актуальную инфу во всяких документах, да тикеты создавать; знать структуру бизнеса, кто куда как соединяется, етс.

S>·>Упихать всё в хедеры — я не представляю какой монстр получится.
S>Всё, наверное, не упихаешь. Но вот если мы хотим ввести какое-то ужесточение в существующем API (а это бывает очень часто), или там планируем перенести этот API на другой адрес/в другой DC, то можем это легко проанонсить при помощи тех самых warning. Ну вот появилось у вас в версии 1.2 API поле "адрес получателя денег". Сначала оно optional, чтобы не сломать существующих клиентов. Но — c warning. Чтобы был повод забеспокоиться.
S>Народ начинает осваивать обязательность, и в версии 1.3 оно становится обязательным, и те, кто игнорировал warninigs, получают 4хх с соответствующим объектом ошибки.
Так же можно "наказывать" тех, кто игнорирует емейлы. Вот только емейл будет один, а хедеров миллионы.

S>Постепенно клиенты привыкают обращать внимание на warnings, потому что это выгоднее, чем их игнорировать.
Возможно это и сработает в каких-то случаях, но как универсальное решение ну никак не годится. Так я и представил как в каждое из десятка миллиона сообщений в день вдруг мы запихнём какой-то хедер и заспамим логи и мониторинг.

S>>>Особенно с учётом того, что предлагаемое вами решение я проверял, и оно меня не устраивает.
S>·>Зато работает.
S>Как по мне — так нет. Регулярные опоздания с внедрением изменений на 12-18 месяцев — плохой результат. Надо лучше.
Так 12-18мес не потому что хедера не было, а потому что люди должны что-то делать. Как десяток тысяч людей заставить что-то сделать быстрее с помощью хедера — не очень понимаю.