Что такое API и как он помогает в создании программных систем
Программы, как люди, общаются между собой. Разбираемся, как это происходит с помощью API.
Популярный термин API (англ. Application Programming Interface — программный интерфейс приложения) — это набор способов и правил, по которым различные программы общаются между собой и обмениваются данными.
Все эти коммуникации происходят с помощью функций, классов, методов, структур, а иногда констант одной программы, к которым могут обращаться другие. Это основной принцип работы API.
Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.
Почему API называют интерфейсом
Интерфейс — это граница между двумя функциональными системами, на которой происходит их взаимодействие и обмен информацией. Но при этом процессы внутри каждой из систем скрыты друг от друга.
С помощью интерфейса можно использовать возможности разных систем, не задумываясь о том, как они обрабатывают наши запросы и что у них «под капотом». Например, чтобы позвонить, совсем не обязательно знать, как смартфон обрабатывает нажатия на тачскрин. Важно лишь, что у гаджета есть «кнопка», всегда возвращающая одинаковый результат в ответ на определённые действия.
Точно так же с помощью вызовов API можно выполнить определённые функции программы, не зная, как она работает. Поэтому API и называют интерфейсом.
Как API помогают писать надёжные программы
Программную (и не только) систему, внутреннее устройство которой скрыто или не важно при решении текущей задачи, принято называть « чёрным ящиком» — потому что мы не знаем/не принимаем во внимание то, что там происходит. А само сокрытие деталей реализации — уровнем абстракции.
Уровни абстракции сильно ускоряют процесс разработки, потому что программист может использовать готовые функции API в других приложениях. Это обычная практика. Например, большинство операционных систем предоставляют свои API другим программам, чтобы они получили возможность:
Windows, Linux или OS X сами определяют, какие функции нужно вызвать и какие параметры передать, чтобы были выполнены те или иные действия. Всё это описывается в документации к API, с которым работают разработчики других программ.
Если создатели API выпускают обновление, которое исправляет ошибки, устраняет уязвимости или улучшает производительность, все приложения, использующие это API, автоматически станут работать лучше.
Если какой-то API для облачных вычислений станет быстрее извлекать квадратный корень, то и все использующие его программы тоже начнут работать быстрее: от онлайн-калькуляторов до нейросетей.
Почему API так популярны у программистов
Стороннее API обычно безопаснее, потому что над ним работает коммерческая организация или целое сообщество разработчиков.
Какие функций могут входить в API
Никаких специальных правил или ограничений на набор функций для API нет — разработчики включают в него то, что позволит клиентам использовать нужные возможности приложения.
Например, в API для анализа текстов будут функции поиска всех однокоренных слов, подсчёта количества союзов, выявления часто встречающихся словосочетаний и так далее.
Функции API могут решать не только утилитарные задачи конкретных приложений. Это может стать элементом маркетинга, когда доступ к API предлагается в виде отдельной услуги.
Как компании зарабатывают с помощью API
Компании, разрабатывающие сложные программные системы, часто предоставляют клиентам доступ к API своих продуктов. Например, создатели видеоредактора могут брать дополнительную плату за рендеринг видео на своих серверах. По API они принимают от клиентов все файлы и инструкции, а возвращают готовый ролик.
Так, скажем, Яндекс, помимо прочего, предоставляет платный API своих технологий:
Популярные социальные сети тоже предоставляют доступ к своим API. Через них можно, например, создать игру для ВКонтакте или добавить на сайт авторизацию через Facebook.
При этом компании обычно не раскрывают принципы реализации своих API, поэтому для программистов они остаются «чёрными ящиками».
Как происходит вызов функций API
Способ вызова функции API описывается в документации.
Вот пример вызова методов библиотек в языке Python:
Если API предоставляет функции через интернет (WebAPI), нужно отправить на сервер HTTP-запрос с данными в формате JSON. Пример синтеза речи с помощью API Yandex.SpeechKit:
Этого достаточно, чтобы получить следующее аудио:
Также бывают косвенные вызовы API — когда вызов происходит при участии посредника (другой функции или другого API). Например, когда пользователь нажимает кнопку «Обновить», он тоже взаимодействует с API браузера. Но делает это не напрямую, а через графический интерфейс.
Что в итоге
С развитием технологий использование API, вероятно, станет повсеместным. Даже простейшие встраиваемые системы, вроде «умного утюга», которые состоят из одной программы, сейчас всё активнее подключаются к интернету вещей. Для этого тоже используют API.
Программисту нужно не только уметь создавать свои интерфейсы для взаимодействия программ, но и знать, как использовать чужие. Научиться работать с API вы сможете на наших курсах по программированию — выбирайте любой и становитесь востребованным специалистом.
27 февраля 2020 г. Краткий обзор API platform для разработки Symfony приложений
Существует много вариантов реализации REST API в symfony приложении. Один из них — API Platform. Из «коробки» мы получаем поддержку REST API протокола, документацию, Swagger UI с возможностью протестировать работу наших эндпоинтов.
Быстрый старт
Добавляем API platform в приложение:
По умолчанию swagger UI активен и доступен по ссылке http://localhost/api:
Пока ни один эндпоинт (операция в терминологии API Platform) не определен, сделать это несложно — достаточно добавить аннотацию @ApiResource к сущности.
Появился полный набор CRUD операций. Все операции делятся на 2 группы:
Collection operations:
Item operations:
Конфигурацию элемента можно описывать в аннотации, xml или yaml файлах. Расположение yaml файлов определяется параметром path конфигурационного файла config/packages/api_platform.yaml
При необходимости можем ограничить набор операций нужным списком:
Постраничный вывод коллекции
Коллекции элементов поддерживают постраничную разбивку.
Валидация
При необходимости выполнить проверку вводимых данных достаточно добавить валидатор на свойство сущности — API platform генерирует сообщение об ошибке.
при строке более 50 символов получим ошибку:
Связанные объекты
Для обеспечения уникальности идентификаторов объектов API platform использует IRI (Internationalized Resource Identifier). IRI каждого объекта совпадает с GET запросом этого объекта /api/customer/123. Этот же тип идентификатора используется и при запросах добавления и редактирования объектов.
Добавим новую сущность, связанную с сущностью Customer:
Тело запроса на добавление нового элемента будет выглядеть так:
Список элементов коллекции будет выглядеть следующим образом:
Как видно список сообщений представлен в виде массива строк IRI:
А запрос http://localhost/api/messages/1 даст такой результат:
Но, при необходимости, используя группы сериализации мы можем вывести не только IRI объекта, но и данные вложенного объекта. Для этого для item operation GET укажем группу сериализации.
Добавим группу к свойствам объекта Message и Customer. Теперь результат того же запроса будет другим:
Фильтры
API platform имеет встроенный механизм фильтров:
Doctrine ORM и Mongo ODM
Elasticsearch
Фильтры сериализации
Также есть возможность определять пользовательские типы фильтров:
Для примера добавим фильтр по строковым полям:
Мы добавили 2 фильтра:
Использование Data Transfer Objects (DTO)
При необходимости мы можем использовать не сущности напрямую, а DTO. Для этого нужно выполнить 3 шага:
Добавляем классы DTO в описание сущности:
Data Transformer для входного DTO:
Data Transformer для выходного DTO:
Данная реализация имеет один небольшой недостаток — не будет работать валидация DTO. Для исправления данного дефекта нужно изменить класс трансформера input DTO:
Пользовательские контроллеры
В том случае, если ни один из вышеперечисленных способов не позволяет получить необходимый нам результат, мы можем использовать собственный контроллер.
Вариант 2
И добавляем класс контроллера:
Пользовательские источники данных
Доступ к данным с использованием Doctrine ORM и Elasticsearch-PHP включены в API Platform как стандартные. Doctrine ORM активно сразу после установки, Elasticsearch-PHP можно включить в конфигурационном файле.
Для других вариантов источников данных мы можем определить свой собственный источник данных добавив новый класс, реализовав интерфейсы CollectionDataProviderInterface, RestrictedDataProviderInterface для провайдера коллекции. или ItemDataProviderInterface, RestrictedDataProviderInterface для провайдера элемента коллекции. Изменением данных занимается другой провайдер, который реализует интерфейс ContextAwareDataPersisterInterface.
Впечатления, выводы.
API Platform намного обширнее, чем было описано в этом обзоре. За его рамками остались автоматизированная генерация документации и json схем, управление сериализацией, безопасность и разграничение доступа, собственные расширения платформы, интеграция с Symfony Messenger и другой функционал. Полное описание можно найти в официальной документации https://api-platform.com/docs/. Целью же данной статьи было первое знакомство с инструментом.
API Platform включает в себя большой арсенал инструментов для написания REST API, позволяющие минимальным количеством кода реализовать большинство задач, возникающих при написании REST API Backend. В то же время, любые действия, которые не укладываются в CRUD, придется самостоятельно реализовывать в виде стандартных контроллеров.
Современный мир держится на API
Сегодняшний мир держится на интерфейсах прикладного программирования — API. С ними стало возможным получать данные и потреблять услуги через веб-приложения, мобильные приложения и устройства, подключенные к сети. Все чаще взаимодействие в интернете выполняются именно через API. Благодаря API появляются новые модели ведения бизнеса, а интернет стал универсальной бизнес-платформой.
API не имеет индустриальной привязки, компании из разных сфер экономики видят в их использовании ценность для своего бизнеса. В свою очередь, рынок программного обеспечения для управления API стремительно развивается, об этом свидетельствуют отчеты Gartner и Forrester.
Всего несколько лет назад взаимодействие между разными подразделениями одного и того же бизнеса обычно обеспечивалось через интеграционную шину. Но модель взаимодействия через API-портал — портал, на котором публикуются API — оказалась настолько удобной, что теперь ее используют и внутри компаний.
Как же получилось, что, даже выбирая модель взаимодействия между подразделениями, компании склоняются сегодня к решениям на основе API? В чем суть актуальной технологической модели и каковы новые правила игры?
Открытые API — мода или необходимость?
В Европе интерес к инновациям в области финансовых потоков поддержала платежная директива Европарламента PSD2, выпущенная для создания более равномерного, прозрачного и открытого рынка платежей, который будет содействовать инновациям, конкуренции и безопасности. В России развитие открытых API официально признано ключевым элементом, необходимым для эффективной интеграции систем участников финансового рынка.
Российское государство и его финансовый сектор уже осознали необходимость открытого банкинга. Предоставление банковских API внешним организациям признано ключевым элементом, необходимым для эффективной интеграции систем участников финансового рынка, инициативы выпуска открытых API поддерживают Центробанк, портал Банки.ру, Московская биржа, «Национальный клиринговый центр» и «Национальный расчетный депозитарий». Отдельные банки уже сформулировали свою стратегию открытого банкинга, определились с моделью дальнейших действий, официально анонсировали доступ к своим системам и сервисам через открытые API и приступили к соответствующим работам.
Список API на webMethods API portal
Отечественные операторы мобильной связи тоже предлагают новые платформы с API для развития бизнесов своих партнеров. Это позволит телекоммуникационным провайдерам поддерживать своих партнеров, объединяя их предложения и расширяя для них рынок сбыта.
Российские банки и телекоммуникационные провайдеры — это именно те предприятия, которые первыми осознали себя как разработчики программного обеспечения, а рынок — как большую цифровую платформу для управления продуктами, настройки маркетинговых акций и взаимодействия с потенциальными клиентами. Продуктовые команды, заказчики, компании и клиенты понимают, что чем более открытыми они будут, тем более открытыми будут их продукты, и тем быстрее они будут интегрироваться в общую экосистему тех рынков, на которых они работают. Поэтому они и используют открытые API — разумный и эффективный способ взаимодействия разработчиков, который позволяет драматически сократить время выхода новых продуктов на рынок.
Кроме того, открытые API представляют своим партнерам такие разработчики программного обеспечения, как «Яндекс». Почта России тоже предлагает интеграцию с внешними приложениями через API, что позволяет встроить сервисы Почты России в сторонние сайты, приложения, системы учета и документооборота — например, добавлять на сайты функции отслеживания отправлений.
И, конечно, создание продуктов с открытыми API естественно для самих разработчиков программного обеспечения, таких как Software AG. Чем полнее их продукты будут документированы и чем лучше они будут управляться, тем больше будет у них пользователей.
Но управление открытыми API никому не дано свыше. Оно невозможно без соответствующего технологического стека.
Кто разрабатывает API-платформы и как они работают
Согласно вышеупомянутому «волшебному квадранту» агентства Gartner, лидерами на рынке систем управления полным жизненным циклом API являются компании Google, CA Technologies, IBM, Software AG, MuleSoft, Red Hat и TIBCO Software. Агентство Forrester в своем недавнем исследовании называет лидерами компании IBM, Google, Software AG, Rogue Wave Software и WSO2.
Согласно отчету Forrester: «API являются ключевой основой для цифровой трансформации. Они способствуют оптимизации клиентского опыта, создают интегрированные цифровые экосистемы клиентов и партнеров, позволяют компаниям извлекать выгоду из прорывных цифровых инноваций, повышать операционную эффективность и закладывают основу для платформенных бизнес-моделей… Решения для управления API играют центральную роль в управлении отношениями между поставщиками и пользователями API, разработчики и поставщики приложений должны рассматривать их как бизнес-приложения, исключительно важные для успеха цифрового бизнеса».
Интерфейс администрирования API
«Не обеспечив полноценного управления жизненным циклом API, нельзя создать платформу для цифровой стратегии, построить экосистему и запустить эффективные продукты», — добавляет в своем отчете Gartner.
Что же обеспечивают системы для управления полным жизненным циклом API? Обычно в технологический стек управления жизненным циклом API входят средства публикации API на удобном для чтения портале, основным пользователем которого являются сторонние разработчики, среда эксплуатации, потребления, обслуживания, управления версиями API и средства их вывода из эксплуатации. Некоторые разработчики (в их числе Software AG) предоставляют также средства планирования, проектирования, внедрения и тестирования API.
Мы в компании Software AG занимались управлением API, когда это еще называлось «внутренним взаимодействием». Мы расширяли и совершенствовали связующее программное обеспечение, решения для интеграции приложений, системы для создания сервисной шины предприятия и инструментарий для создания систем, основанных на сервисно-ориентированной архитектуре.
В 2004 г. в дополнение к нашей интеграционной шине мы создали продукт B2B Trading Networks, предназначенный для межпартнерского взаимодействия и обмена данными. В нем были реализованы вполне классические пользовательские сценарии межпартнерского взаимодействия, включая постоянный мониторинг, сервис, обмен данными по итогам операционного дня. Тогда это еще не называлось открытыми API.
Наконец, пять лет назад мы представили полный жизненный цикл управления API в рамках платформы управления API webMethods. В 2014 г. мы запустили webMethods API Portal для разработчиков API, а в 2016 г. объединили функционал API-шлюз webMethods API Gateway, портала и средств медиации и управления жизненным циклом в одну платформу. Эти средства поддерживают разработку API, их сборку, одобрение и публикацию в принятом технологическом стандарте и являются частью платформы Software AG Hybrid Integration & API.
Выбор спецификации API
Как выбрать API-платформу
Агентство Forrester считает, что при выборе решения для управления API нужно, в первую очередь, учитывать, является ли предлагаемое решение комплексным — то есть содержит портал для разработчиков API, портал для управления API и API-шлюз. Особо отмечено, что некоторые решения предоставляют дополнительные компоненты, такие как инструменты проектирования и разработки API, интеграционные платформы, платформы управления услугами в режиме реального времени и т. п.
Далее Forrester подчеркивает, что решение для управления API должно быть настоящим автономным продуктом, отделяемым от любых связанных с ним платформ, интеграционных продуктов или бизнес-приложений.
Наконец, авторы отчета считают, что стоит доверять тем разработчикам решений, которые имеют ряд полноценных внедрений. Клиентами решения Software AG для управления API являются Michael Kors (производитель и поставщик одежды и аксессуаров высокого класса), American Electric Power (одна из крупнейших североамериканских энергетических компаний), Outerwall (поставщик автоматизированных киосков для розничных продаж), Dick’s Sporting Goods (розничная сеть спортивных товаров), EDF (крупнейшая французская государственная энергогенерирующая компания и крупнейшая в мире компания-оператор атомных электростанций) и др.
К этому списку параметров стоит добавить еще несколько факторов, которые необходимо принимать во внимание при выборе API-платформы.
1. В разных отраслях экономика работает по-разному и имеет разные схемы монетизации. Оцените план развития API-платформы, которую вы рассматриваете. Отражает ли она реалии вашего сегмента бизнеса? Важно определить бизнес-задачу внедрения, сформировать список бизнес-требований к решению и из него вывести список функциональных и архитектурных требований. Возможно, этот список определит выбор не только API-решения, но и дополнительных компонентов.
Управление политиками API
2. Очень важно, чтобы ваша API-платформа соответствовала ожиданиям ваших заказчиков, а точнее — их ИТ-отделов. Платформа должна быть удобна для внедрения и работы, она должна поддерживать комфортную для заказчиков технологическую модель развертывания (облачную, на физических ресурсах или гибридную), ее функциональность должна соответствовать их текущим потребностям, а план ее развития — их будущим потребностям на год или два вперед.
3. API-портал должен иметь широкие возможности аналитики, тестовые интерфейсы для разработчиков, возможность генерировать документацию на основе метаданных API. Он должен обеспечивать социальное сотрудничество разработчиков, генерацию клиентских SDK и средства монетизации.
Генерация клиентских SDK
4. API-шлюз должен обеспечивать безопасность (аутентификацию, авторизацию, управление политиками безопасности, защиту от атак), медиацию сервисов, возможности маршрутизации и балансировки нагрузки.
Подтверждение регистрации пользователя
5. Средства управления жизненным циклом API должны обеспечивать и оценивать взаимосвязь внутренних и внешних сервисов, микросервисов и обычных служб, технических и бизнес-сервисов, а также поддержку разных типов «активов» в каталоге.
6. Очень важен вопрос общей стоимости владения решениями, которая зависит от скорости разработки продуктов и времени их вывода на рынок — а на это влияют и практики, принятые у разработчиков, и используемые ими технологии.
7. Вопрос, на который у разработчиков API-платформ часто нет ответа — каким образом будет создаваться контракт между заказчиком и партнером и как будет работать биллинг – скорее всего у вендора есть рекомендации по реализации технологической возможности создания контракта.
Что ж, на самом деле в API нет ничего нового — просто раньше они были внутренними. Из-за сегодняшней волны интереса к API многим уже кажется, что этой аббревиатурой всегда обозначались способы взаимодействия компаний через интернет, но на самом деле API предоставляют способы взаимодействия продуктов, технологических сервисов и их потребителей, которые могут принадлежать как разным игрокам рынка, компаниям и заказчикам, так и разным бизнес-группам внутри компании.
Наш интеграционный продукт существует и развивается много лет, он стабилен и зрел, его используют многие заказчики. Чтобы оценить его самостоятельно, посетите нашу веб-страницу бесплатного тестового программного обеспечения, где вы легко найдете различные компоненты платформы webMethods. Протестируйте webMethods API Cloud Free Trial прямо сейчас и расскажите нам о своих впечатлениях.
Что такое API
Содержание
— А зачем это мне? Я вообще-то web тестирую! Вот если пойду в автоматизацию, тогда да… Ну, еще это в enterprise тестируют, я слышал…
А вот и нет! Про API полезно знать любому тестировщику. Потому что по нему системы взаимодействуют между собой. И это взаимодействие вы видите каждый день даже на самых простых и захудалых сайтах.
Любая оплата идет через API платежной системы. Купил билет в кино? Маечку в онлайн-магазине? Книжку? Как только жмешь «оплатить», сайт соединяет тебя с платежной системой.
Но даже если у вас нет интеграции с другими системами, у вас всё равно есть API! Потому что система внутри себя тоже общается по api. И пока фронт-разработчик усиленно пилит GUI (графический интерфейс), вы можете:
Что такое API
API (Application programming interface) — это контракт, который предоставляет программа. «Ко мне можно обращаться так и так, я обязуюсь делать то и это».
Если переводить на русский, это было бы слово «договор». Договор между двумя сторонами, как договор на покупку машины:
API — набор функций
Когда вы покупаете машину, вы составляете договор, в котором прописываете все важные для вас пункты. Точно также и между программами должны составляться договоры. Они указывают, как к той или иной программе можно обращаться.
Соответственно, API отвечает на вопрос “Как ко мне, к моей системе можно обратиться?”, и включает в себя:
Тут вы можете мне сказать:
— Хмм, погоди. Операция, данные на входе, данные на выходе — как-то всё это очень сильно похоже на описание функции!
Если вы когда-то сталкивались с разработкой или просто изучали язык программирования, вы наверняка знаете, что такое функция. Фактически у нас есть данные на входе, есть данные на выходе, и некая магия, которая преобразует одно в другое.
И да! Вы будете правы в том, что определения похожи. Почему? Да потому что API — это набор функций. Это может быть одна функция, а может быть много.
Как составляется набор функций
Да без разницы как. Как разработчик захочет, так и сгруппирует. Например, можно группировать API по функционалу. То есть:
Можно не группировать вообще, а делать одно общее API.
Можно сделать одно общее API, а остальные «под заказ». Если у вас коробочный продукт, то в него обычно входит набор стандартных функций. А любые хотелки заказчиков выносятся отдельно.
Получается, что в нашей системе есть несколько разных API, на каждое из которых у нас написан контракт. В каждом контракте четко прописано, какие операции можно выполнять, какие функции там будут
И конечно, функции можно переиспользовать. То есть одну и ту же функцию можно включать в разные наборы, в разные апи. Никто этого не запрещает.
Получается, что разработчик придумывает, какое у него будет API. Либо делает общее, либо распределяет по функционалу или каким-то своим критериям, и в каждое апи добавляет тот набор функций, который ему необходим.
При чем тут слово «интерфейс»
— Минуточку, Оля! Ты же сама выше писала, что API — это Application programming interface. Почему ты тогда говоришь о контракте, хотя там слово интерфейс?
Да потому, что в программировании контракт — это и есть интерфейс. В классическом описании ООП (объектно-ориентированного программирования) есть 3 кита:
Не всегда программа предоставляет именно графический интерфейс. Это может быть SOAP, REST интерфейс, или другое API. Чтобы использовать этот интерфейс, вы должны понимать:
Как вызывается API
Вызвать апи можно как напрямую, так и косвенно.
Вызов API напрямую
1. Система вызывает функции внутри себя
Разные части программы как-то общаются между собой. Они делают это на программном уровне, то есть на уровне API!
Это самый «простой» в использовании способ, потому что автор API, которое вызывается — разработчик. И он же его потребитель! А значит, проблемы с неактуальной документацией нет =)
Шучу, проблемы с документацией есть всегда. Просто в этом случае в качестве документации будут комментарии в коде. А они, увы, тоже бывают неактуальны. Или разработчики разные, или один, но уже забыл, как делал исходное api и как оно должно работать…
2. Система вызывает метод другой системы
А вот это типичный кейс, которые тестируют тестировщики в интеграторах. Или тестировщики, которые проверяют интеграцию своей системы с чужой.
Одна система дергает через api какой-то метод другой системы. Она может попытаться получить данные из другой системы. Или наоборот, отправить данные в эту систему.
Допустим, я решила подключить подсказки из Дадаты к своему интернет-магазинчику, чтобы пользователь легко ввел адрес доставки.
Я подключаю подсказки по API. И теперь, когда пользователь начинает вводить адрес на моем сайте, он видит подсказки из Дадаты. Как это получается:
И, конечно, не забываем про кейс, когда мы разрабатываем именно API-метод. Который только через SOAP и можно вызвать, в интерфейсе его нигде нет. Что Заказчик заказал, то мы и сделали ¯\_(ツ)_/¯
Пример можно посмотреть в Users. Метод MagicSearch создан на основе реальных событий. Хотя надо признать, в оригинале логика еще замудренее была, я то под свой сайт подстраивала.
Но тут фишка в том, что в самой системе в пользовательском интерфейсе есть только обычный поиск, просто строка ввода. Ну, может, парочка фильтров. А вот для интеграции нужна была целая куча доп возможностей, что и было сделано через SOAP-метод.
Функционал супер-поиска доступен только по API, пользователь в интерфейсе его никак не пощупает.
В этом случае у вас обычно есть ТЗ, согласно которому работает API-метод. Ваша задача — проверить его. Типичная задача тестировщика, просто добавьте к стандартным тестам на тест-дизайн особенности тестирования API, и дело в шляпе!
(что именно надо тестировать в API — я расскажу отдельной статьей чуть позднее)
3. Человек вызывает метод
Для примера снова идем в Users. Если мы хотим создать пользователя, надо заполнить уйму полей!
Конечно, это можно сделать в помощью специальных плагинов типа Form Filler. Но что, если вам нужны адекватные тестовые данные под вашу систему? И на русском языке?
Заполнение полей вручную — грустно и уныло! А уж если это надо повторять каждую неделю или день на чистой тестовой базе — вообще кошмар. Это сразу первый приоритет на автоматизацию рутинных действий.
И в данном случае роль автоматизатора выполняет… Postman. Пользователя можно создать через REST-запрос CreateUser. Один раз прописали нормальные “как настоящие” данные, каждый раз пользуемся. Профит!
Вместо ручного заполнения формы (1 минута бездумного заполнения полей значениями «лпрулпк») получаем 1 секунду нажатия на кнопку «Send». При этом значения будут намного адекватнее.
А еще в постмане можно сделать отдельную папку подготовки тестовой базы, напихать туда десяток запросов. И вот уже на любой базе за пару секунд вы получаете столько данных, сколько вручную вбивали бы часами!
Если вы нашли баг и не понимаете, на кого его вешать — разработчика front-end или back-end, уберите все лишнее. Вызовите метод без графического интерфейса. А еще вы можете тестировать логику программы, пока интерфейс не готов или сломан.
4. Автотесты дергают методы
Есть типичная пирамида автоматизации:
Слово API как бы намекает на то, что будет использовано в тестах ツ
GUI-тесты — честный тест, робот делает все, что делал бы пользователь. Открывает браузер, тыкает на кнопочки… Но если что-то упадет, будете долго разбираться, где именно.
API-тесты — все то же самое, только без браузера. Мы просто подаем данные на вход и проверяем данные на выходе. Например, можно внести итоговый ответ в эксельку, и пусть робот выверяет ее, правильно ли заполняются данные? Локализовать проблему становится проще.
Unit-тесты — это когда мы проверяем каждую функцию отдельно. Отдельно смотрим расчет для ячейки 1, отдельно — для ячейки 2, и так далее. Такие тесты шустрее всего гоняются и баги по ним легко локализовать.
Косвенный вызов API
Когда пользователь работает с GUI, на самом деле он тоже работает с API. Просто не знает об этом, ему это просто не нужно.
То есть когда пользователь открывает систему и пытается загрузить отчет, ему не важно, как работает система, какой там magic внутри. У него есть кнопочка «загрузить отчет», на которую он и нажимает. Пользователь работает через GUI (графический пользовательский интерфейс).
Но на самом деле под этим графическим пользовательским интерфейсом находится API. И когда пользователь нажимает на кнопочку, кнопочка вызывает функцию построения отчета.
А функция построения отчета уже может вызывать 10 разных других функций, если ей это необходимо.
И вот уже пользователь видит перед собой готовый отчет. Он вызвал сложное API, даже не подозревая об этом!
Что значит «Тестирование API»
В первую очередь, мы подразумеваем тестирование ЧЕРЕЗ API. «Тестирование API» — общеупотребимый термин, так действительно говорят, но технически термин некорректен. Мы не тестируем API, мы не тестируем GUI (графический интерфейс). Мы тестируем какую-то функциональность через графический или программный интерфейс.
Но это устоявшееся выражение. Можно использовать его и говорить “тестирование API”. И когда мы про это говорим, мы имеем в виду:
Когда мы говорим про тестирование API, чаще всего мы подразумеваем тестирование Remote API. Когда у нас есть две системы, находящихся на разных компьютерах, которые как-то между собой общаются.
И если вы видите в вакансии «тестирование API», скорее всего это подразумевает умение вызвать SOAP или REST сервис и протестировать его. Хотя всегда стоит уточнить!
Резюме
API (Application programming interface) — это контракт, который предоставляет программа. «Ко мне можно обращаться так и так, я обязуюсь делать то и это».
