15 вопросов, которые вы должны задать об их API, прежде чем выбирать платформу
Хороший друг и наставник написал мне вопрос, и я хотел бы использовать мои ответы для этого сообщения. Его вопросы были немного больше сосредоточены на одной отрасли (электронная почта), поэтому я обобщил свои ответы на все API. Он спросил, какие вопросы компании следует задать поставщику об их API, прежде чем делать выбор.
Зачем вам нужны API?
An интерфейс прикладного программирования (API) - это интерфейс, предоставляемый компьютерной системой, библиотекой или приложением, чтобы разрешать запросы на услуги, которые могут быть сделаны из них другими компьютерными программами, и / или позволять обмен данными между ними.
Википедия.
Подобно тому, как вы вводите URL-адрес и получаете ответ на веб-странице, API - это метод, с помощью которого ваши системы могут запрашивать и получать ответ для синхронизации данных между ними. Поскольку компании стремятся к цифровой трансформации, автоматизация задач с помощью API-интерфейсов - отличный способ повысить эффективность внутри организации и уменьшить количество человеческих ошибок.
API-интерфейсы играют центральную роль в автоматизации, особенно в маркетинговых приложениях. Одна из проблем при покупке хорошего поставщика с комплексным API в том, что о ресурсах и расходах на разработку обычно думают позже. Маркетинговая группа или директор по маркетингу могут стимулировать покупку приложения, а иногда команда разработчиков не получает большого вклада.
Для исследования возможностей интеграции платформы через API требуется нечто большее, чем простой вопрос, А есть API? И следующий вопрос:
Какие типы API существуют?
Существует множество различных типов технологий API, каждая из которых имеет свои особенности и варианты использования. Тип технологии API, которая лучше всего подходит для вашего приложения, будет зависеть от ваших конкретных потребностей и требований. Вот 6 распространенных типов технологий API:
- API REST – ОТДЫХ API — это тип веб-API, который использует методы HTTP (такие как GET, POST, PUT и DELETE) для извлечения данных и управления ими. API-интерфейсы REST спроектированы так, чтобы быть легкими и гибкими, и часто используются для создания веб-приложений и мобильных приложений.
- API-интерфейсы SOAP – SOAP- (Простой протокол доступа к объектам) API — это тип веб-API, который использует XML (расширяемый язык разметки) для кодирования данных и их передачи по протоколу HTTP. API-интерфейсы SOAP более стандартизированы и структурированы, чем API-интерфейсы REST, и часто используются в корпоративных средах, где важны безопасность и надежность.
- API GraphQL — GraphQL — это язык запросов для API, который позволяет разработчикам запрашивать определенные данные из API, а не получать фиксированный набор данных. API-интерфейсы GraphQL являются гибкими и позволяют разработчикам запрашивать только те данные, которые им нужны, что может повысить производительность и сократить потери данных.
- Webhooks – Веб-перехватчики — это тип технологии API, которая позволяет серверу отправлять данные клиенту в режиме реального времени, вместо того, чтобы клиент запрашивал данные с сервера. Веб-перехватчики часто используются для обеспечения связи между приложениями в режиме реального времени и запуска действий при возникновении определенных событий.
- Облачные API – Облачные API позволяют разработчикам получать доступ к службам облачных вычислений, таким как хранилище, базы данных и аналитика, и взаимодействовать с ними. Эти API могут помочь разработчикам создавать и развертывать приложения более эффективно и результативно.
- Аппаратные API – Аппаратные API позволяют разработчикам получать доступ к аппаратным устройствам, таким как датчики, камеры и принтеры, и управлять ими. Эти API можно использовать для создания приложений, взаимодействующих с физическими устройствами и управляющих ими.
Если вы войдете в систему с приложением с плохо поддерживаемым или документированным API, вы сведете свою команду разработчиков с ума, и ваши интеграции, скорее всего, не будут выполнены или вообще не удастся. Найдите подходящего поставщика, и ваша интеграция будет работать, а ваши разработчики будут рады помочь!
Вопросы для исследования их возможностей API:
- Пробел в функциях - Определите, какие функции их пользовательского интерфейса доступны через интерфейс прикладного программирования. Какие функции API есть, которых нет в пользовательском интерфейсе, и наоборот?
- Шкала - Спросите, сколько звонков на их API ежедневно. Есть ли у них выделенный пул серверов? Количество невероятно важно, поскольку вы хотите определить, является ли API второстепенным или фактически частью стратегии компании.
- Документация - Запросите документацию по API. Он должен быть надежным, подробно описывая все функции и переменные, доступные в API.
- Сообщество - Спросите, есть ли у них онлайн-сообщество разработчиков, где можно делиться кодом и идеями с другими разработчиками. Сообщества разработчиков являются ключом к быстрому и эффективному запуску ваших усилий по разработке и интеграции. Вместо того, чтобы привлекать «специалистов по API» в компании, вы также привлекаете всех их клиентов, у которых уже были испытания и ошибки при интеграции их решения.
- Типы API – Знакомство с типом API, который вы используете, интеграция может быть довольно простой. Однако верно и обратное, если вы не знакомы с функциями и требованиями для использования API.
- Языки - Спросите, с какими платформами и приложениями они успешно интегрировались, и запросите контакты, чтобы вы могли узнать от этих клиентов, насколько сложно было интегрироваться и насколько хорошо работает API.
- ограничения - Спросите, какие ограничения у поставщика на количество звонков в час, в день, в неделю и т. Д. Если у вас нет масштабируемого поставщика, ваш рост будет ограничен заказчиком.
- образцы - Предлагают ли они библиотеку примеров кода, чтобы легко начать работу? Многие компании публикуют SDK (комплекты разработки программного обеспечения) для разных языков и платформ, что ускоряет сроки интеграции.
- Песочница - Предлагают ли они непроизводственную конечную точку или среду песочницы, в которой вы можете протестировать свой код?
- Ресурсы - Спросите, есть ли у них в компании выделенные ресурсы интеграции. Есть ли у них внутренняя консультационная группа, доступная для интеграции? Если так, добавьте несколько часов в контракт!
- Безопасность - Как они проходят аутентификацию с помощью API? Это учетные данные пользователя, ключи или другие методики? Могут ли они ограничивать запросы по IP-адресу?
- Uptime - Спросите, какие у них API время безотказной работы и частота ошибок, а также время их обслуживания. Кроме того, важны стратегии их обхода. Есть ли у них внутренние процессы, которые будут повторять попытки API звонит в случае, если запись недоступна из-за другого процесса? Это то, что они разработали в своем решении?
- SLA - Есть ли у них Соглашение об уровне обслуживания где время безотказной работы должно быть выше 99.9%?
- Roadmap - Какие будущие функции они включают в свой API и каковы ожидаемые графики доставки?
- Интеграции - Какие производственные интеграции они разработали или разработали сторонние компании? Иногда компании могут отказаться от внутренней разработки функций, когда другая производственная интеграция уже существует и поддерживается.
Ключ к этим вопросам заключается в том, что интеграция «женит» вас на платформе. Вы же не хотите жениться на ком-то, не узнав о нем как можно больше, не так ли? Именно это происходит, когда люди покупают платформу, не зная ее интеграционных возможностей.
Помимо API, вы также должны попытаться выяснить, какие еще ресурсы интеграции у них могут быть: штрих-кодирование, картографирование, службы очистки данных, RSS, веб-формы, виджеты, формальные партнерские интеграции, механизмы сценариев, SFTP капли и др.