Процесс разработки открытых API

[abitrolly]

Нельзя вот так вот взять и сделать открытый API.

Если там не будет нужных методов, он будет не открытый, если они будут неудобные, он тоже будет не открытый. Оценить удобство и пользу невозможно без наличия API. Получается проблема курицы и яйца - пока нет API мы не знаем можно на нём сделать, а пока мы не знаем, что мы можем сделать, нам не дают API.

Поэтому нужен органичный итеративный процесс для эволюции API. Чтобы эволюция была возможна:

1. API разбит на классы (может не класс, а другое название)
2. У каждого класса API есть версия
3. У API есть тесты и инструкции по переходу к новому API

Процесс эволюции происходит через истории пользователя. История - это понятный обычному человеку рассказ, чего другой человек хочет достичь. Когда есть история, дальше идёт развитие сюжета - как в этом API ему помогает (или не помогает) и как мы его изменяем. Каждая история ведёт к изменению (или не ведёт), но каждый такой шаг освещается каждую неделю максимально открыто. Это позволяет людям синхронизироваться, чтобы подключаться к дискуссии и предлагать варианты получше. Здесь важно:

1. скорость изменений
2. период стабилизации
3. учёт и уведомление пользователей, которые могут постадать от сломанных апи

Без обратной связи от пользователей, без сообщества и обмена опытом с другими странами есть вероятность, что API станет локальным. Возможно появятся классы API по пользователям (харкорный API для legacy система банков, человеческий API для новых веб сервисов и т.п.).

Связь со всеми надо поддерживать, ревью делать, тесты, спеки писать, доки править. Информационная инфраструктура требует денег тоже - сервера, ДНСы, это всё надо считать, т.к. хороший (надёжный и логичный) API - основной компонент эффективной инфраструктуры. Стоимость должна быть понятна, прозрачна, а значит тоже открыта, т.е. считаться.

1. Бюджет (сколько уже есть)
2. Стоимость поддержки работ по опен апи и сообщества (люди)
3. Стоимость инфраструктуры (фактическая, расчётная, для пользователей)
4. Варианты участия - донаты, экон.геймплей, гос.бюджет, и т.д.

Основное требование - открытость, вовлечение, паралельный (разработке решений) и итеративный процесс, и за пол-года год можно получить масштабируемое решение для Европы в т.ч.

[bamunra]

Толя, до 10и полезных API я тебе могу предоставить не вопрос. Это будет аналог живых банковских API. Можно больше, но там пойдёт узкая специализация.

2й пункт. Сколько людей понадобится? 4й - Плата с банков за тестирование. Они предоставляют API мы его тестируем на соответствие стандартам и если всё ок, то регистрируем и дальше берём на саппорт. +Плата от пользователей API. Разработать универсальную формулу, чтоб посильно было как маленьким стартапам так и приличным не стыдно. Получается что мы прослойка между банками и разработчиками. Банки тестят только свои API, разработчики тестят только своё ПО, мы выносим вердикт о соответствии. Получается сервис предоставляющий автоматическое тестирование и разработка стандартов.

[abitrolly]

@chertby @R0bur, @bamunra. Смотрите что творится. )

Состоялось заседание рабочей группы по направлению «Развитие открытых интерфейсов прикладного программирования»

обсудили запланированные на 2020 год мероприятия, а также новые инициативы и проекты в рамках направления.

Какие мероприятия? Какие инициативы? Какие проекты? Непаханный край работы, чтобы процесс разработки открытых интерфейсов сделать открытым. )

Приглашаем всех заинтересованных к более активному участию в инициировании и реализации проектов и инициатив в сфере цифровых финансовых технологий в Республике Беларусь.

Какие мысли по этому поводу? Мне кажется надо вступать, в смысле воспользоваться приглашением. Вопрос только на что можно подписываться, и на каких условиях. Разрабатывать открытые API со всем best practices и публичным R&D открыто я готов, а бесплатно нет. )