Чек-лист запуска публичного API
Важно понимать, зачем вы делаете публичный API. Опасная практика — делать API публичным просто потому, что он у вас есть. Появятся более приоритетные проекты, вы перестанете уделять API достаточно внимания, а пострадают в конечном итоге ваши пользователи.
Сформулируйте условия использования
Подумайте не только о том, как можно использовать ваш API, но и о том, какое использование вы считаете неприемлемым.
Оцените, какие нагрузки предстоит выдержать, чтобы обеспечить работоспособность API.
Чётко пропишите, как именно разработчики должны представлять или использовать ваш бренд в своих проектах.
Изучите рынок и определитесь с моделью монетизации.
Если вы отдаёте исходный код, не забудьте про лицензию на код. Если отдаёте данные — про лицензию на базу. Если в вашем коде используются компоненты, лицензия которых требует указания копирайтов (MIT, (L)GPL, BSD), подумайте, где и как эти копирайты будут показываться.
Привлеките профессионального юриста для подготовки финального документа пользовательского соглашения.
Спроектируйте и разработайте API
Послушайте наш рассказ о проектировании архитектуры API. Он поможет разобраться в ключевых моментах — начиная с того, о ком должен думать разработчик в начале работы, и заканчивая секретами «безболезненного» рефакторинга.
Продумайте, какие задачи ваш API должен решать в первую очередь, и напишите пример кода, с помощью которого он будет это делать.
Тестирование API сильно отличается от тестирования пользовательских сервисов. Заранее продумайте процедуру с вашими тестировщиками.
Определитесь с номенклатурой сущностей, уровнями абстракции и ответственностью компонентов системы.
Помогите использовать API
Документация — основа любого API. Пользователи вашего API не обладают даром телепатии и смогут использовать ваш сервис только в том случае, если у них будет подробная инструкция.
Когда вы напишете очень много примеров, напишите еще немножко примеров. Именно они помогут разработчикам больше всего. А чтобы примеры было удобнее изучать, сделайте Песочницу.
Существуют разные способы сделать документацию более удобной. Например, для API Яндекс.Диска был выбран стандарт Swagger. Благодаря наличию Swagger-документации появился проект Полигон, который позволяет разработчикам отправлять боевые запросы в API, не написав ни строчки кода.
Простые виджеты и конструкторы, SDK и библиотеки для различных языков станут хорошим подспорьем для всех пользователей вашего API.
Не бросайте своих пользователей
Пользователям обязательно нужна возможность связаться с провайдером API по телефону или по электронной почте.
Отдельный форум или ветка в рамках существующих площадок заметно облегчат жизнь и вам, и вашим пользователям. Находя ответы на форуме, люди будут меньше вам писать.
Распределите темы между членами команды. Пусть каждый отвечает только на свою часть вопросов.
Расскажите о вашем API
Создайте для API отдельный сайт или раздел на сайте.
Рассказывайте разработчикам о вашем API и отвечайте на их вопросы.
Пишите статьи, инструкции, описывайте, как вы реализовали ту или иную функциональность. Вы не только привлечёте внимание к вашей технологии, но и сделаете её более понятной.