как узнать есть ли у сайта api
Как разобраться в API HTML?
Автор статьи, перевод которой мы сегодня публикуем, решил разобрать несколько HTML5-API и поговорить об их возможностях, о том, для чего они созданы, об особенностях их использования и об их ограничениях.
Что такое API?
Сокращение API расшифровывается как Application Programming Interface, что обычно переводится как «программный интерфейс приложения» или «интерфейс прикладного программирования». API широко используются в программировании для организации взаимодействия серверных приложений. API позволяют двум сервисам взаимодействовать друг с другом, не зная при этом о деталях реализации друг друга. API — это важнейший аспект проектирования систем, имеющий отношение к абстракции, к одной из фундаментальных концепций информатики.
API HTML5
Существует точка зрения, в соответствии с которой HTML5, язык разметки, не имеет программных интерфейсов. А «API HTML» — это, на самом деле, JavaScript-API, выдающие ответы, представленные в формате HTML. Это так из-за того, что API обычно создают для организации взаимодействия серверных программ.
Это заблуждение можно связать с тем фактом, что спецификация HTML5, определённая W3C, в основном, касается семантических элементов HTML. Большинство рассмотренных возможностей API HTML воспринимаются как продвинутые способы работы с HTML, а не как интерфейсы прикладного программирования. Спецификации API HTML5 можно найти в документации WHATWG (Web Hypertext Application Technology Working Group).
Если почитать документацию WHATWG, то можно заметить, что JavaScript там практически не упоминается, и что для понимания API HTML5 не нужно знать JavaScript.
Вот что об этом пишет Леа Веру в материале об API HTML: «В API HTML определения и протоколы находятся в самом HTML. Инструменты обращаются к HTML за конфигурационными сведениями. API HTML обычно представлены определёнными наборами классов и атрибутов, которые можно использовать в обычном HTML-коде».
Фронтенд-разработчики обычно бегло знакомятся с API HTML прежде чем создавать UI-библиотеки, заменяющие их возможности. Здесь мы поговорим о некоторых API HTML.
API Geolocation
API Geolocation позволяет веб-сервисам получать сведения о географическом положении пользователи. Из-за того, что подобные сведения ставят под угрозу безопасность пользователя и его личные данные, эти сведения не доступны приложениям до тех пор, пока пользователь не даст согласие на работу с ними. После того, как согласие дано, что обычно выражается в щелчке пользователя по соответствующей кнопке особого диалогового окна, сведения о его местоположении могут быть получены и использованы приложением.
Географическая информация может оказаться очень ценной для некоторых приложений, функционирование которых завязано на знании о том, где именно находится пользователь. Это, например, службы медицинской помощи, спортивные приложения, приложения-карты, даже маркетинговые приложения. Все эти приложения могут получить большую пользу от знания того, где находится пользователь, и того, что находится поблизости от него.
Если говорить об ограничениях API Geolocation, то можно отметить следующие:
API Drag and Drop
Перетаскивание объектов (Drag and Drop, DnD), это простая процедура, позволяющая пользователю перемещать элементы из одного места экрана программы в другое. В данном случае речь идёт о включении возможности перетаскивания элементов. Функционал этого API позволяет программистам создавать простые онлайн-игры, вроде шахмат, где можно перетаскивать по доске шахматные фигуры. Процесс перетаскивания элементов по экрану устроен довольно просто:
Для того чтобы элемент можно было бы перетаскивать, его атрибут draggable должен быть установлен в true :
Если реализовывать DnD-механизмы с использованием API HTML5, можно ожидать полной поддержки этих механизмах в специфических окружениях, а так же минимизации разного рода неожиданностей, которые могут возникнуть в процессе перетаскивания элементов. Одним из ограничений данного API можно назвать тот факт, что он не даёт возможностей управлять происходящим в процессе перетаскивания элемента.
API Web Storage
Появление API Web Storage сыграло очень важную роль в веб-разработке, так как эти API позволяют веб-приложениям сохранять различные данные в хранилище браузера. Локальное хранение данных и возможность организации доступа к ним без необходимости предварительной передачи этих данных по сети открывают для приложения массу ценных возможностей. До появления API Web Storage HTML5 разработчики не могли хранить локально значительные объёмы информации. Данные пользователя приходилось сохранять в куки-файлах. А ведь эти файлы ориентированы на организацию взаимодействия с сервером и их нужно передавать на сервер в каждом HTTP-запросе.
API Web Storage предлагают разработчикам возможность хранения на клиенте значительных объёмов информации, которая изменяется сравнительно редко, и передача которой по сети означает необходимость неоправданной траты времени и системных ресурсов. У API Web Storage есть и другие преимущества перед куки-файлами, например — это возможность хранения больших объёмов информации, это улучшения в сфере безопасности. В результате API Web Storage нашёл применение во многих сценариях.
API Web Storage предлагает разработчику два уникальных механизма, направленных на решение различных задач. Это — локальное хранилище (local storage) и сессионное хранилище (session storage).
API Web Speech
API Web Speech состоит из двух основных частей. Это — SpeechSynthesis (синтез речи, эта технология известна как Text to Speech или TTS) и SpeechRecognition (распознавание речи). Реализация API Web Speech в браузерах дала возможность организовывать речевое взаимодействия пользователя и браузера, выполняемое посредством голосовых команд. Это, например, голосовой поиск, голосовая навигация, голосовой набор текста.
При использовании этого API всё ещё необходимо пользоваться префиксами браузеров, оно доступно лишь в Chrome и Firefox. Оно, кроме того, использует серверный API Google для распознавания речи. Из-за того, что этот API основан на взаимодействии с серверными ресурсами, пользоваться им можно лишь при подключении к интернету.
Одним из недостатков этого API является тот факт, что разрешение на его использование запрашивается лишь один раз, а после этого система считает, что использование этого API разрешено и не запрашивает повторных разрешений. Этот недостаток может стать причиной ухудшения защиты данных пользователей, так как вредоносная программа способна незаметно записывать или прослушивать речь пользователя после того, как пользователь дал первое и единственное разрешение на работу с этим API.
API WebRTC
API WebRTC предназначен для организации взаимодействия систем в режиме реального времени. Возможности этого API позволяют реализовывать пиринговый обмен файлами между пользователями, проводить телеконференции, выполнять потоковую передачу звука и видеоизображения.
API WebRTC позволяет работать с аудио- и видео-потоками устройств, подключённых к компьютеру, таких, как видеокамеры и микрофоны, без необходимости использования сторонних плагинов.
Этот API поддерживают все современные браузеры и даже клиенты для мобильных платформ, таких, как Android и iOS.
Модель обмена данными, реализованная в API WebRTC отличается от других коммуникационных моделей. Для обеспечения работы этого API в браузерах имеются реализации других API. Вот некоторые из них:
Другие API
Мы рассмотрели лишь некоторые API, описанные в спецификациях W3C и WHATWG. Существуют и многие другие API, о которых стоит упомянуть. Среди них отметим следующие:
Итоги
За HTML5-атрибутами скрываются мощные API, упрощающие разработку веб-проектов. Они позволяют сделать работу со страницами более интерактивной. Но, к сожалению, на них часто не обращают внимания, отдавая предпочтение JavaScript-реализациям стандартных механизмов.
В разговоре об HTML5-API стоит учитывать тот факт, что они постоянно развиваются. А по мере их развития сглаживаются различия в их реализации в разных браузерах.
Вот что сказано об HTML5-API в одной публикации InfoWorld: «API HTML5, конечно, нельзя назвать универсальным средством для разработки мобильных приложений. Всему своё время и место. Это касается и HTML5-приложений, и нативных приложений, которые всё ещё актуальны».
Не каждая веб-страница и не каждое веб-приложение нуждается в HTML5-API. Но понимание того, что они такое, того, как они работают, знание их сильных и слабых сторон поможет программисту принять решение о том, что именно лучше всего подходит для решения стоящих перед ним задач.
Какими API HTML5 вы пользуетесь чаще всего?
Анализ сайта API
API Анализа — это интерфейс, который представляет из себя набор команд, выполняющих тесты из Анализа сайтов. Данные, полученные через API Анализа, можно использовать как конструктор, чтобы создавать новые сервисы, приложения и виджеты. В API вы получаете все данных о более 70 тестов, историю данный и возможность обновления данных.
Как получить данные
Данные отдаются в формате JSON. Для получения данных необходимо сделать соответствующий запрос.
Получение базового анализа (GET-запрос)
Получение статуса базового анализа (GET-запрос)
Обновление базового анализа (POST запрос)
Получение расширенного анализа (GET-запрос)
Получение статуса расширенного анализа (GET-запрос)
Обновление расширенного анализа (POST-запрос)
%KEY% — ваш ключ. Который можно получить в настройках.
%DOMAIN% — проверяемый домен.
Примеры и использование
Наше API чаще всего используются студиями для быстрого анализа, мониторинга и создания отчетов.
Как можно использовать:
White-label анализ сайта
Полностью рабочий анализ сайта в вашем оформлении у вас на сайте.
Помощь для создания клиентского аудита сайта
Вы получаете все данные по сайту клиента и пишите свои тексты на каждый тест. После, аудит передается клиенту.
Массовый мониторинг
Через API вы получаете данные по списку ваших сайтов, смотрите историю и отслеживаете показания на своей стороне.
Другое
Различные боты для мессенджеров, виджеты, создание отчетов и другое.
Пример скрипта, для вывода нескольких тестов из анализа.
Как узнать есть ли у сайта api
В этой статье мы разберем, как получить и использовать API сайта, если по нему нет документации или оно еще не открыто официально. Руководство написано для новичков, которые еще не пробовали зареверсить простой API. Для тех же кто сам занимался подобным ничего нового здесь нет. Разбор проведем на примере API сервиса https://www.captionbot.ai/ который недавно открыл Microsoft (спасибо им за это). Многие могли прочитать о нем в статье на Geektimes. Сайт использует ajax запросы в формате JSON, поэтому скопировать их будет легко и приятно. Поехали!
Экспериментальная функция:
Ниже вы видите текст статьи по ссылке. По нему можно быстро понять ссылка достойна прочтения или нет
Просим обратить внимание, что текст по ссылке и здесь может не совпадать.
В этой статье мы разберем, как получить и использовать API сайта, если по нему нет документации или оно еще не открыто официально. Руководство написано для новичков, которые еще не пробовали зареверсить простой API. Для тех же кто сам занимался подобным ничего нового здесь нет.
Разбор проведем на примере API сервиса https://www.captionbot.ai/ который недавно открыл Microsoft (спасибо им за это). Многие могли прочитать о нем в статье на Geektimes. Сайт использует ajax запросы в формате JSON, поэтому скопировать их будет легко и приятно. Поехали!
Анализируем запросы
В первую очередь открываем инструменты разработчика и анализируем запросы, которые сайт посылает на сервер.
В нашем случае все интересующие нас запросы имеют базовый URL https://www.captionbot.ai/api
Инициализация
Запомним это и идем дальше.
Отправка URL
У нас есть два способа загрузить изображение: через URL и через загрузку файла. Для теста берем URL изображения Лены с вики и отсылаем. В сетевой активности появляется POST запрос на /api/message со следующими параметрами:
Зачем-то закодировали JSON дважды, ну да ладно. В человеческом виде это выглядит так:
Загрузка изображения
Далее, не закрывая вкладку, пробуем ту же операцию с загрузкой фото из локального файла. Видим POST запрос на /api/upload в формате multipart/form-data с названием поля file :
В ответ получаем строку URL нашего загруженного файла, можем перейти по нему и убедиться в этом:
Затем отсылается уже знакомый нам запрос на /api/message :
Пишем обертку
Чтобы использовать полученные знания с удобством, делаем простую обертку на вашем любимом языке программирования. Я сделаю это на Python. Для запросов к сайту использую requests, так как он удобный и в нем есть сессии, которые хранят cookie за меня. Сайт использует SSL, но по дефолту requests будет ругаться на сертификат:
Решается это установкой флага verify=False при каждом запросе.
Исходный код есть на Github, плюс готовый пакет в pip.
API в современных приложениях
API или Application Programming Interface можно встретить в большинстве современных приложений и вебсайтов. Уже из названия понятно, что это интерфейс, предлагающий разработчикам готовые блоки для создания приложений. Когда ты пишешь приложение, ты обращаешься к такой «библиотеке» и берешь оттуда необходимые данные.
Пока что все выглядит просто и понятно. Надеемся, что так будет и в дальнейшем и ты быстро разберешься в теме и научиться применять API в своих приложениях. А если нет, то мы постараемся помочь тебе в понимании того, что такое Application Programming Interface и где он применяется.
Что же такое Интернет? Это огромная сеть серверов, связанных между собой. На них и хранятся все сайты, которые ты можешь видеть, когда вводишь определенный УРЛ в строку браузера. В принципе, сервером может стать и твой рабочий ноутбук. Он будет обслуживать твой сайт в сети, например. Кстати, разработчики, работающие над сайтами, создают их на локальных серверах и только после отладки запускают во всемирную паутину для публичного доступа.
Например, если ты введешь в строку браузера twitter.com, то на удаленный сервер популярной соцсети будет отправлен запрос. После получения ответа, браузер отображает страницу. Всякий раз, когда ты заходишь на ту или иную страницу, ты уже взаимодействует с API.
В некоторых компаниях API идет как готовый продукт. Например, если это метеорологический сервис, покупая доступ к Application Programming interface, ты получаешь метеорологические данные.
А теперь посмотрим на то, как можно использовать API в своих собственных приложениях. Один из самых простых примеров – написание приложения, в котором пользователь сможет получать данные по погоде в своем городе. Для этого нам необходимо подготовить HTML макет и подключить соответствующий API, а затем, с помощью нескольких функций заставить это приложение работать.
Как пишется HTML код под приложение, мы здесь разбирать не будем, в этом нет смысла. Приложение писалось в библиотеке React, поэтому тем, кто с ней еще не знаком, некоторые моменты могут быть не совсем понятны, но мы поясним по ходу разъяснения.
Итак, для получения доступа к серверу, мы сделаем функцию, в которой будет запрос к серверу с метеорологическими данными. Это нужно для того, чтобы в последующем, пользователь нашего приложения мог получать данные о погоде в любой момент.
Как это происходит? Пользователь твоего приложения хочет узнать, например, погоду в Москве. Для этого, он вбивает название города в поиск, который ты уже внедрил в приложение и получает результат.
В программе же этот результат достигается следующим образом. Функция getWeather отправляет запрос на сервер и получает ответ.
Дальше, в этой же функции мы спрашиваем, отвечает ли нам сервер. Если статус 404, значит мы не записываем никакие данные. А пользователь увидит undefined, ну или что-то другое, по твоему усмотрению. Если же сервер отвечает, мы записываем ответы в state и, когда пользователь будет вводить, например, «Москва» в поиске приложения, у него отобразятся данные именно по Москве (в нашем случае это температура, название города, страны, погодные условия)
Это пример на React, но ты можешь сделать все это на чистом JS без проблем. Самое главное – понять, как все это работает. Как ты мог убедиться, принцип здесь тоже очень простой – отправка запроса на сервер, получение статуса сервера. Если он недоступен, ты в приложении сообщаешь об этом пользователю, например, в графе «Температура» будет написано «Неизвестно» или любой другой вариант.
Если же сервер доступен, пользователь увидит температуру в своем городе, название города, страну и погодные условия.
А вот как выглядит API Европейского центрального банка. Его можно использовать, например, при создании простейшего конвертера валют. Как видишь, здесь просто объект, в котором есть стандартный набор ключ:значение. Получая доступ к этому серверу, ты можешь сделать конвертер, который поможет твоим пользователям рассчитать курс интересующих их валют.
И это далеко не все. Сегодня очень многие приложения и вебсайты предлагают свои API разработчикам. Например, такой интерфейс есть на сайте GitHub, где в базе можно получить информацию по всем пользователям и определенным критериям. API есть на криптовалютных биржах и с их помощью ты можешь создать свое приложение, которое будет «подтягивать» самые последние и актуальные котировки. Тот же CoinmarketCap работает по этому же принципу. Через Application Programming Interface они получают данные с большинства крупных и не только бирж о токенах.
Все интерфейсы разделен по категориям. То есть, если тебе нужны метео сервисы, ты просто находишь такую категорию и смотришь результаты.
После этого откроется страница, на которой будут представлены все API нужной категории.
Выбрав подходящий интерфейс, можно переходить к его описанию и документации. Она представлена следующим образом
Как видишь, все очень подробно. Очень многие API в свободном доступе, поэтому если ты сейчас изучаешь, например, JS или библиотеку типа React, ты можешь тренироваться с такими API в написании своих приложений для портфолио. Сервис требует регистрацию, пройти которую можно в том числе с помощью социальных сетей.
Существует два основных типа API – публичные и приватные. Первые встречаются в таких приложениях, как Slack или Shopify. Здесь разработчики делают упор на то, что интерфейсы могут использоваться на сторонних платформах. Подключение к такому API совершенно бесплатно, как и его использование.
Есть также приватные API. Они используются, в основном, внутри компаний. Если у фирмы множество внутренних продуктов, для взаимодействия между ними задействуется такой приватный интерфейс.
Самыми часто используемыми интерфейсами этого типа являются:
Наверное, ты уже понял, хотя бы отчасти, зачем приложению нужен API. Приведем наиболее частые ситуации, когда в твоих приложениях ты будешь использовать такой интерфейс:
В принципе. На этом можно было бы и закончить, ведь ты уже создал интерфейс, пусть, как говорится пользуются (платно или бесплатно, определять тебе). Но на самом деле, это недостаточно. Каким образом пользователи будут обращаться к интерфейсу?
Конечно, это может быть стандартный набор HTTP запросов для получения искомой информации. Но это неправильный подход. Наиболее подходящий вариант – создание собственной библиотеки, которая и будет работать с API и где ты опишешь все самые необходимые способы получения и отправки данных.
Первое, что сразу же приходит на ум –Octokit от GitHub. Это яркий пример таких библиотек. Что касается документации, в ней содержится вся необходимая информация для того, чтобы пользователь библиотеки знал, как отыскать требуемую информацию.
Итак, если ты планируешь создание своего собственного API, возможно, тебе стоит позаботиться и о том, чтобы создать к нему библиотеки. Кстати, если твое приложение будет пользоваться большой популярностью, возможно, кто-то другой создаст библиотеку для работы с API твоего софта.
Наверняка ты видел на страницах с приложениями заветное слово API. Это значит, что ты можешь создать свое собственное приложение и использовать готовый API на определенных условиях (бесплатно, платно, за регистрацию и так далее).
В качестве примера, можно привести API Github. Здесь ты получишь всю информацию о пользователе, его аватарке, подписчиках, репозиториях и иные интересные данные. А если взять API Twitter, здесь можно получить информацию о пользователях, твитах, подписчиках и так далее. Такая информация может быть действительно крайне полезной при разработке сторонних приложений.
Теперь ты знаешь, что такое Application Programming Interface. Ты можешь применять его в своих приложениях или создать приложение и разработать свой API для него, чтобы другие пользовались им.
Что такое 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) — это контракт, который предоставляет программа. «Ко мне можно обращаться так и так, я обязуюсь делать то и это».
Контракт включает в себя: