Чек-лист запуска публичного 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 и отвечайте на их вопросы.
Пишите статьи, инструкции, описывайте, как вы реализовали ту или иную функциональность. Вы не только привлечёте внимание к вашей технологии, но и сделаете её более понятной.
Нашли ли вы ответ для решения вашей задачи?
Спасибо за участие в опросе.
Мы хотим получше узнать посетителей tech.yandex.ru. Расскажете, чем вы занимаетесь?
Нам важно знать, зачем люди приходят на tech.yandex.ru. Расскажете, что вы ищете?
Ошибка
Не удалось отправить отзыв
Спасибо!
Ваши ответы помогут нам улучшать сервис каждый день