Skip to content

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

Description

@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. Варианты участия - донаты, экон.геймплей, гос.бюджет, и т.д.

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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions