[Перевод] Интеграция API — это кошмар
А вам казалось, что соединение API друг с другом — это нескончаемая битва?
Сейчас у нас уже есть машины, которые умнее людей. Но мы до сих пор не можем как следует справиться с интеграцией API. Что не так с API, которые часто становятся для разработчиков камнем преткновения? Интернету примерно 55 лет. Всемирной Паутине — 34 года. Даже JSON уже 18, я не шучу. За всё это время так и не найден простой способ соединять API. Почему так складывается, и почему мы общими силами не можем этого исправить? Читайте дальше.
Проблема интеграции API не нова. На самом деле, основная цель API — сочленять различные приложения. Разрабатывая приложение, мы можем реализовать через API некоторые фичи, нужные нам в этом приложении. Легко считать, что разработка приложений зависит от API. Особенно в веб-приложениях предполагается, что хорошая соединяемость должна быть гарантирована.
Почему же интеграция с API может вызывать сложности, и из-за чего разработчики испытывают по поводу API растущую фрустрацию? Дело в том, что API, вообще-то, должны упрощать жизнь разработчикам. Но реальность такова, что при обеспечении интеграции часто приходится иметь дело с плохой документацией и пытаться понять несочетаемые форматы. Так ты оказываешься в бесконечном цикле, состоящем из проб и ошибок.
Первое препятствие на пути разработчиков при работе с API — документацию ещё нужно понять. По некоторым API есть грамотно написанные и регулярно обновляемые руководства и туториалы. Но в большинстве случаев у вас в распоряжении будет только автоматически сгенерированная справка по API, в которой просто продемонстрировано, что этот API может делать. Вам как разработчику придётся полностью прочитать справку, чтобы понять операции, параметры и отклики. Уже после этого вам придётся придумать, как обработать ваш случай, имея в распоряжении эти операции. Когда вы определитесь с тем, какие операции использовать, можно приступать к экспериментам, чтобы проверить, как именно всё устроено.
Второй раздражитель проявляется именно в ходе экспериментов. Если вам удастся преодолеть аутентификацию и наладить отправку запросов к API, то вы просто будете стараться убедиться, что операции действуют именно так, как описано в справке. Часто будут обнаруживаться несоответствия. Иногда упоминаются уже не существующие параметры. Либо находятся отклики, дающие такой побочный эффект, который даже не документирован. Вам кажется, что ваши попытки действовать по справке ни к чему не приводят. Если есть SDK — попробуйте им воспользоваться.
Наконец, устаревшие SDK — третий раздражитель разработчиков. Представьте: вы установили SDK и обнаружили, что предоставляемые в нём инструменты в некоторых ситуациях не работают как следует. Хуже того, вы замечаете, что SDK не удаётся приспособить к вашим конкретным нуждам. Иногда даже приходится прибегать к обратной разработке SDK и писать собственную обёртку для коммуникации с API. Если у вас всё получилось, и написанный вами код проходит все тесты — развёртывайте ваше решение. Вот тут появляется повод для беспокойства.
После того, как ваш код выведен в продакшен, вы обязаны убедиться, что он работает без проблем. Если вам непросто гарантировать это даже для вашего собственного кода, представьте, насколько сложно дать такие гарантии для API, который поддерживаете не вы, а кто-то ещё. Провайдер API работает в своём темпе и иногда вносит в этот API изменения. Иногда такие изменения нарушают всю интеграцию, которую вы написали ранее, иногда тот API, с которым вы интегрировались, перестаёт работать или начинает вести себя хаотически. Ваше решение приходит в неудовлетворительный вид. Из-за всего этого у вас поднимается давление и начинается бессонница.
Причём, всё это может случиться с одним-единственным API. Теперь представьте себе, что будет, если потребуется интегрировать несколько API. Что, если вы выстраиваете рабочий поток, в котором участвуют различные операции, предоставляемые различными провайдерами API — тогда поводов для беспокойства в разы больше. Вдруг приходится иметь дело с несовместимостью между откликами от одного API и полезной нагрузкой в запросах, поступающих от другого. А весь код, который вам придётся написать, должен объяснять, как различным операциям взаимодействовать на общем языке. Как только будут внесены любые изменения, можно не сомневаться, что случатся те или иные отказы.
Все эти поводы для беспокойства существуют, поскольку не все API соответствуют одинаковым стандартам и паттернам. Поскольку провайдеры вправе реализовывать свои API так, как считают нужным, лёгкое взаимодействие между этими API не гарантируется. Кроме того, приходится беспокоиться об управлении рабочими потоками. Потребуется предусмотреть все взаимодействия между операциями. Я имею в виду, что в случае отказа нужно будет организовать повторные запросы, нужно будет обрабатывать ограничение частоты, обеспечить безопасное хранение токенов аутентификации, а также временно сохранять состояние между операциями. Если откажет хотя бы один из этих аспектов, то всё решение может перестать работать.
Но это не неизбежность. Существует множество решений, позволяющих вам работать с имеющимися API без всех этих проблем. Некоторые решения ориентированы на тех, кто вообще не хочет писать никакой код, а другие рассчитаны на то, что все операции над потоками задач будут полностью программироваться. Подвержены ли ошибкам такие решения, как и любые другие? Определённо. Но усилия, необходимые для устранения проблем с одним интеграционным решением, не сравнятся с отладкой множества операций API. Все мы сами выбираем, на что хотим потратить время и силы. Я предпочитаю разумно тратить время именно на те вещи, которые добавляют ценности, а не заниматься отладкой отдельных запросов, связанных с эксплуатацией API.
P.S. Обращаем ваше внимание на то, что у нас на сайте проходит распродажа.
Habrahabr.ru прочитано 708 раз
