Что такое API

    Содержание



    Слово «API» мелькает в вакансиях даже для начинающих тестировщиков. То REST API, то SOAP API, то просто API. Что же это за зверь такой? Давайте разбираться!

    — А зачем это мне? Я вообще-то web тестирую! Вот если пойду в автоматизацию, тогда да… Ну, еще это в enterprise тестируют, я слышал…

    А вот и нет! Про API полезно знать любому тестировщику. Потому что по нему системы взаимодействуют между собой. И это взаимодействие вы видите каждый день даже на самых простых и захудалых сайтах.
    Любая оплата идет через API платежной системы. Купил билет в кино? Маечку в онлайн-магазине? Книжку? Как только жмешь «оплатить», сайт соединяет тебя с платежной системой.

    Но даже если у вас нет интеграции с другими системами, у вас всё равно есть API! Потому что система внутри себя тоже общается по api. И пока фронт-разработчик усиленно пилит GUI (графический интерфейс), вы можете:

    • скучать в ожидании;
    • проверять логику работы по API

    Конечно, я за второй вариант! Так что давайте разбираться, что же такое API. Можно посмотреть видео на youtube, или прочитать дальше в виде статьи.

    Что такое API


    image

    API (Application programming interface) — это контракт, который предоставляет программа. «Ко мне можно обращаться так и так, я обязуюсь делать то и это».

    Если переводить на русский, это было бы слово «договор». Договор между двумя сторонами, как договор на покупку машины:

    • мои обязанности — внести такую то сумму,
    • обязанность продавца — дать машину.

    Перевести можно, да. Но никто так не делает ¯\_(ツ)_/¯

    Все используют слово «контракт». Так принято. К тому же это слово входит в название стиля разработки:

    • Code first — сначала пишем код, потом по нему генерируем контракт
    • Contract first — сначала создаем контракт, потом по нему пишем или генерируем код (в этой статье я буду говорить именно об этом стиле)

    Мы же не говорим «контракт на продажу машины»? Вот и разработчики не говорят «договор». Негласное соглашение.

    API — набор функций


    Когда вы покупаете машину, вы составляете договор, в котором прописываете все важные для вас пункты. Точно также и между программами должны составляться договоры. Они указывают, как к той или иной программе можно обращаться.

    Соответственно, API отвечает на вопрос “Как ко мне, к моей системе можно обратиться?”, и включает в себя:

    • саму операцию, которую мы можем выполнить,
    • данные, которые поступают на вход,
    • данные, которые оказываются на выходе (контент данных или сообщение об ошибке).

    image

    Тут вы можете мне сказать:

    — Хмм, погоди. Операция, данные на входе, данные на выходе — как-то всё это очень сильно похоже на описание функции!

    Если вы когда-то сталкивались с разработкой или просто изучали язык программирования, вы наверняка знаете, что такое функция. Фактически у нас есть данные на входе, есть данные на выходе, и некая магия, которая преобразует одно в другое.

    И да! Вы будете правы в том, что определения похожи. Почему? Да потому что API — это набор функций. Это может быть одна функция, а может быть много.

    image

    Как составляется набор функций


    Да без разницы как. Как разработчик захочет, так и сгруппирует. Например, можно группировать API по функционалу. То есть:

    • отдельно API для входа в систему, где будет регистрация и авторизация;
    • отдельно API для отчетности — отчет 1, отчет 2, отчет 3… отчет N. Для разных отчетов у нас разные формулы = разные функции. И все мы их собираем в один набор, api для отчетности.
    • отдельно API платежек — для работы с каждым банком своя функция.
    • ...

    image

    Можно не группировать вообще, а делать одно общее API.

    Можно сделать одно общее API, а остальные «под заказ». Если у вас коробочный продукт, то в него обычно входит набор стандартных функций. А любые хотелки заказчиков выносятся отдельно.

    image

    Получается, что в нашей системе есть несколько разных API, на каждое из которых у нас написан контракт. В каждом контракте четко прописано, какие операции можно выполнять, какие функции там будут

    image

    И конечно, функции можно переиспользовать. То есть одну и ту же функцию можно включать в разные наборы, в разные апи. Никто этого не запрещает.

    image

    Получается, что разработчик придумывает, какое у него будет API. Либо делает общее, либо распределяет по функционалу или каким-то своим критериям, и в каждое апи добавляет тот набор функций, который ему необходим.

    При чем тут слово «интерфейс»


    — Минуточку, Оля! Ты же сама выше писала, что API — это Application programming interface. Почему ты тогда говоришь о контракте, хотя там слово интерфейс?

    Да потому, что в программировании контракт — это и есть интерфейс. В классическом описании ООП (объектно-ориентированного программирования) есть 3 кита:

    1. Инкапсуляция
    2. Наследование
    3. Полиморфизм

    Инкапсуляция — это когда мы скрываем реализацию. Для пользователя все легко и понятно. Нажал на кнопочку — получил отчет. А как это работает изнутри — ему все равно. Какая база данных скрыта под капотом? Oracle? MySQL? На каком языке программирования написана программа? Как именно организован код? Не суть. Программа предоставляет интерфейс, им он и пользуется.

    Не всегда программа предоставляет именно графический интерфейс. Это может быть SOAP, REST интерфейс, или другое API. Чтобы использовать этот интерфейс, вы должны понимать:

    • что подать на вход;
    • что получается на выходе;
    • какие исключения нужно обработать.

    Пользователи работают с GUI — graphical user interface. Программы работают с API — Application programming interface. Им не нужна графика, только контракт.

    Как вызывается API


    Вызвать апи можно как напрямую, так и косвенно.

    Напрямую:

    1. Система вызывает функции внутри себя
    2. Система вызывает метод другой системы
    3. Человек вызывает метод
    4. Автотесты дергают методы

    Косвенно:

    1. Пользователь работает с GUI

    Вызов API напрямую


    1. Система вызывает функции внутри себя


    Разные части программы как-то общаются между собой. Они делают это на программном уровне, то есть на уровне API!

    Это самый «простой» в использовании способ, потому что автор API, которое вызывается — разработчик. И он же его потребитель! А значит, проблемы с неактуальной документацией нет =)

    Шучу, проблемы с документацией есть всегда. Просто в этом случае в качестве документации будут комментарии в коде. А они, увы, тоже бывают неактуальны. Или разработчики разные, или один, но уже забыл, как делал исходное api и как оно должно работать…


    2. Система вызывает метод другой системы


    А вот это типичный кейс, которые тестируют тестировщики в интеграторах. Или тестировщики, которые проверяют интеграцию своей системы с чужой.

    Одна система дергает через api какой-то метод другой системы. Она может попытаться получить данные из другой системы. Или наоборот, отправить данные в эту систему.

    Допустим, я решила подключить подсказки из Дадаты к своему интернет-магазинчику, чтобы пользователь легко ввел адрес доставки.

    Я подключаю подсказки по API. И теперь, когда пользователь начинает вводить адрес на моем сайте, он видит подсказки из Дадаты. Как это получается:

    • Он вводит букву на моем сайте
    • Мой сайт отправляет запрос в подсказки Дадаты по API
    • Дадата возвращает ответ
    • Мой сайт его обрабатывает и отображает результат пользователю

    Вон сколько шагов получилось! И так на каждый введенный символ. Пользователь не видит этого взаимодействия, но оно есть.

    И, конечно, не забываем про кейс, когда мы разрабатываем именно API-метод. Который только через SOAP и можно вызвать, в интерфейсе его нигде нет. Что Заказчик заказал, то мы и сделали ¯\_(ツ)_/¯

    Пример можно посмотреть в Users. Метод MagicSearch создан на основе реальных событий. Хотя надо признать, в оригинале логика еще замудренее была, я то под свой сайт подстраивала.

    Но тут фишка в том, что в самой системе в пользовательском интерфейсе есть только обычный поиск, просто строка ввода. Ну, может, парочка фильтров. А вот для интеграции нужна была целая куча доп возможностей, что и было сделано через SOAP-метод.

    Функционал супер-поиска доступен только по API, пользователь в интерфейсе его никак не пощупает.

    В этом случае у вас обычно есть ТЗ, согласно которому работает API-метод. Ваша задача — проверить его. Типичная задача тестировщика, просто добавьте к стандартным тестам на тест-дизайн особенности тестирования API, и дело в шляпе!

    (что именно надо тестировать в API — я расскажу отдельной статьей чуть позднее)


    3. Человек вызывает метод


    Причины разные:

    1. Для ускорения работы
    2. Для локализации бага (проблема где? На сервере или клиенте?)
    3. Для проверки логики без докруток фронта

    Если система предоставляет API, обычно проще дернуть его, чем делать то же самое через графический интерфейс. Тем более что вызов API можно сохранить в инструменте. Один раз сохранил — на любой базе применяешь, пусть даже она по 10 раз в день чистится.

    Для примера снова идем в Users. Если мы хотим создать пользователя, надо заполнить уйму полей!

    image

    Конечно, это можно сделать в помощью специальных плагинов типа Form Filler. Но что, если вам нужны адекватные тестовые данные под вашу систему? И на русском языке?

    Заполнение полей вручную — грустно и уныло! А уж если это надо повторять каждую неделю или день на чистой тестовой базе — вообще кошмар. Это сразу первый приоритет на автоматизацию рутинных действий.

    И в данном случае роль автоматизатора выполняет… Postman. Пользователя можно создать через REST-запрос CreateUser. Один раз прописали нормальные “как настоящие” данные, каждый раз пользуемся. Профит!

    Вместо ручного заполнения формы (1 минута бездумного заполнения полей значениями «лпрулпк») получаем 1 секунду нажатия на кнопку «Send». При этом значения будут намного адекватнее.

    А еще в постмане можно сделать отдельную папку подготовки тестовой базы, напихать туда десяток запросов. И вот уже на любой базе за пару секунд вы получаете столько данных, сколько вручную вбивали бы часами!

    Если вы нашли баг и не понимаете, на кого его вешать — разработчика front-end или back-end, уберите все лишнее. Вызовите метод без графического интерфейса. А еще вы можете тестировать логику программы, пока интерфейс не готов или сломан.

    4. Автотесты дергают методы


    Есть типичная пирамида автоматизации:

    • GUI-тесты — честный тест, «как это делал бы пользователь».
    • API-тесты — опускаемся на уровень ниже, выкидывая лишнее.
    • Unit-тесты — тесты на отдельную функцию

    image

    Слово API как бы намекает на то, что будет использовано в тестах ツ

    Допустим, у нас есть:

    • операция: загрузка отчета;
    • на входе: данные из ручных или автоматических корректировок или из каких-то других мест;
    • на выходе: отчет, построенный по неким правилам

    Правила построения отчета:

    • Ячейка 1: Х — Y
    • Ячейка 2: Z * 6
    • ...

    image

    GUI-тесты — честный тест, робот делает все, что делал бы пользователь. Открывает браузер, тыкает на кнопочки… Но если что-то упадет, будете долго разбираться, где именно.

    API-тесты — все то же самое, только без браузера. Мы просто подаем данные на вход и проверяем данные на выходе. Например, можно внести итоговый ответ в эксельку, и пусть робот выверяет ее, правильно ли заполняются данные? Локализовать проблему становится проще.

    Unit-тесты — это когда мы проверяем каждую функцию отдельно. Отдельно смотрим расчет для ячейки 1, отдельно — для ячейки 2, и так далее. Такие тесты шустрее всего гоняются и баги по ним легко локализовать.


    Косвенный вызов API


    Когда пользователь работает с GUI, на самом деле он тоже работает с API. Просто не знает об этом, ему это просто не нужно.

    То есть когда пользователь открывает систему и пытается загрузить отчет, ему не важно, как работает система, какой там magic внутри. У него есть кнопочка «загрузить отчет», на которую он и нажимает. Пользователь работает через GUI (графический пользовательский интерфейс).

    image

    Но на самом деле под этим графическим пользовательским интерфейсом находится API. И когда пользователь нажимает на кнопочку, кнопочка вызывает функцию построения отчета.

    image

    А функция построения отчета уже может вызывать 10 разных других функций, если ей это необходимо.

    И вот уже пользователь видит перед собой готовый отчет. Он вызвал сложное API, даже не подозревая об этом!

    Что значит «Тестирование API»


    В первую очередь, мы подразумеваем тестирование ЧЕРЕЗ API. «Тестирование API» — общеупотребимый термин, так действительно говорят, но технически термин некорректен. Мы не тестируем API, мы не тестируем GUI (графический интерфейс). Мы тестируем какую-то функциональность через графический или программный интерфейс.

    Но это устоявшееся выражение. Можно использовать его и говорить “тестирование API”. И когда мы про это говорим, мы имеем в виду:

    • автотесты на уровне API
    • или интеграцию между двумя разными системами.

    Интеграция — когда одна система общается с другой по какому-то протоколу передачи данных. Это называется Remote API, то есть общение по сети, по некоему протоколу (HTTP, JMS и т.д.). В противовес ему есть еще Local API (он же «Shared memory API») — это то API, по которому программа общается сама с собой или общается с другой программой внутри одной виртуальной памяти.

    image

    Когда мы говорим про тестирование API, чаще всего мы подразумеваем тестирование Remote API. Когда у нас есть две системы, находящихся на разных компьютерах, которые как-то между собой общаются.

    И если вы видите в вакансии «тестирование API», скорее всего это подразумевает умение вызвать SOAP или REST сервис и протестировать его. Хотя всегда стоит уточнить!

    Резюме


    API (Application programming interface) — это контракт, который предоставляет программа. «Ко мне можно обращаться так и так, я обязуюсь делать то и это».

    Контракт включает в себя:

    • саму операцию, которую мы можем выполнить,
    • данные, которые поступают на вход,
    • данные, которые оказываются на выходе (контент данных или сообщение об ошибке).
    • ».
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 22

      –6
      Про API полезно знать любому тестировщику. Потому что по нему системы взаимодействуют между собой. И это взаимодействие вы видите каждый день даже на самых простых и захудалых сайтах.

      Золотые слова! Применительно к нашей практике, то многие и многие сайты захудалые или нет (я говоря про сайты где так или иначе используются цифровые сертификаты и электронная подпись) не раскрывают сознательно или нет API, по которому с ними можно общаться. Они говорят возьми то-то и то-то, поставь и все будет работать. А это вообще-то говоря навязывание, отсюда коррупционные схемы и многое другое. И самое главное трудно предложить что-то новое и более совершенное и тем более перейти от MS Windows к отечественным ОС. Это и тормоз импортозамещению. Взгляните на требования к рабочему месту пользователя хоть ФНС, хоть ЕГАИС, хоть мною уважаемые ГОСУСЛУГИ и вы поймете, что до открытости API ой как далеко.

        +1
        А что с ЕГАИС? Насколько помню там не такой уж и большой список требований
          0

          Мы же говорим не про требования к рабочему месту, кто хочет получить доступ в ЕГАИС, а про API, на котором все разработано.
          А что ЕГАИС? Да, там не так все плохо и можно использовать токены PKCS#11 с ГОСТ-ами. Но все работает только под Windows, а это уже нехорошо.

            0
            Насчёт требования к ОС соглашусь. Но насчет API не так уверен. API у ЕГАИС идут для связи с ККТ (контрольно-кассовой техникой) и получением ТТН (Товарно-транспортной накладной) и остальных документов и поработав с ЕГАИС, я не заметил каких-то проблем с этим (кроме тех, когда пользователи сами косячат с номерами, информацией и прочим).
              0

              Согласитесь, ведь было бы совсем здорово, если бы ЕГАИС-у было безразницы на какой платформе работает пользователь. Кстати, ведь все социальные сети не зависят от платформу пользователя, наш же с вами Хабр.
              Понимаете, помимо Linux, есть еще увлеченные люди, которые кроме OS X ничего признавать не хотят.

                0
                Согласен, при кроссплатформенности ПО ЕГАИС было бы лучше для рядового потребителя ввиду меньших затрат на технику при постоянной работе на Linux.
                С другой стороны были бы проблемы с доработкой ПО и обучением работы на нем. Ведь большинство программ, даже для тех же мобильников структура программ и их функционал различен. А если какие-нибудь, допустим партнеры 1С, предоставляют услуги сопровождения предприятия в ЕГАИС, то работнику будет немного проблемно работать минимум на 2 ОС и перестраиваться между ними. Не смотря даже на тоже набор API
                  0
                  С другой стороны были бы проблемы с доработкой ПО и обучением работы на нем. Ведь большинство программ, даже для тех же мобильников структура программ и их функционал различен.

                  А тут вы не правы. Возьмите API PKCS#11 и сделайте всю работу с криптографией (включая создание и проверку подписи) на нем и все будет Ok.
                  Посмотрите сами хотя бы это (здесь пока три платформы). Программы и функционал для всех платформ одинаков.

                    0
                    Возможно мог ошибиться, а что насчет сопутствующего ПО и минимальных требований к ЕГАИС? Jacarta, если не ошибаюсь, без проблем и на Linux подобных работать.
                    А с остальным, в т.ч. и УТМ и 1С есть много проблем, даже на том же Linux, как с установкой, так и с обновлением.
                    Если распространять ЕГАИС и остальное на другие ОС, то надо будет дорабатывать само ПО и поддерживать эго
                      0
                      Jacarta, если не ошибаюсь, без проблем и на Linux подобных работать.

                      Нет, не ошибаетесь. И OS X тоже поддерживается.


                      надо будет дорабатывать само ПО и поддерживать эго

                      Именно про это я и говорю.

                        0
                        А будет ли целесообразно дорабатывать ПО для ОС с % рабочих мест порядка 25%, даже при наличии всего набора API
                          0

                          А как же права меньшинств?

                            0
                            А как же миллионные затраты на доработку и поддержку?
                              0

                              Правительство требует импортозамещение, а оно знает, что делает. -)

                                0
                                Думаю, надо согласиться с вами, т.к. со знающим человеком лучше не спорить
                                  0

                                  Спасибо за комплимент!

        0
        В жестоком реальном мире помимо «что на вход», «что на выходе» и «что делает» есть ещё потребность в описании возможных состояний системы. Даже если хочется делать 100% RESTful…
          –1
          Да вообще потребность во внятном описании есть, да!
            0

            Вот для этого есть DbC (https://en.wikipedia.org/wiki/Design_by_contract). Там правда засада в том, что если уж вы все контракты верифицировали, то тестировать API скорее всего смысла нет.

            0
            Отличная статья! Большое спасибо, все очень понятно и простым языком. Супер
              0
              Спасибо за фидбек!:)
              0
              Спасибо за статью! отличное объяснение.
                0
                Спасибо за отзыв ))

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое