Введение: Что такое API
В широком смысле слова API (Application Programming Interface) это метод который приложение предоставляет внешним пользователям для коммуникации с ним. Обычно через Интернет.
Это может быть взаимодействие с сервером приложения на смартфоне, между компьютерами или другими устройствами.
API применяются там где невозможна или нежелательна непосредственная интеграция с исходным приложением, то есть практически везде.
Крупные интернет-компании обычно предоставляют (платно или бесплатно) доступ к API своих сервисов.
Например:
Одним из самых распространённых способов тестирования API является написание скриптов на Python .
Читайте также статью «Термины Cybersecurity»
Где применяют API
Сейчас будет несколько абстрактных примеров просто для понимания сути.
Конкретные примеры работы с API я разбираю в учебнике
Пример №1:
Если Вы хотите разместить на своём сайте яндекс-карты Вам не нужно устанавливать программы от Яндекса, достаточно послать несколько запросов и Яндекс передаст необходимую информацию.
Это возможно потому, что программисты Яндекса разработали специальный набор запросов - API которые можно присылать к ним на сервер чтобы получить в ответ карту.
Пример №2:
Предположим, что Вы создали сайт vk2.com. Вы хотите, чтобы вебмастера могли добавить на свои сайты возможность комментировать записи используя учётную запись vk2, но раскрывать или раздавать свой код не хотите.
Чтобы обойти эту проблему Вы выкладываете в публичном доступе правила, по которым вебмастера могут обращаться к vk2, чтобы получить комментарии.
Формат этих сообщений это обычно либо JSON либо XML. О них мы поговорим позже.
Повторим для закрепления сути: Смысл в том, что сайт написанный на любом языке, поддерживающем HTTP запросы, не посылает на сервер никаких PHP/C/Python команд, а общается ним с помощью запросов, описанных в API.
Если вам интересен реальный пример работы с API рекомендую статью Работа с API GitHub
Endpoint
Адрес, на который посылаются сообщения называется Endpoint.
Обычно это URL (например, название сайта) и порт. Если я хочу создать веб сервис на порту 8080 Endpoint будет выглядеть так:
http://andreyolegovich.ru:8080
Слово адрес нужно понимать в общем смысле - как при отправке бумажного письма нужно написать на конверте физический адрес, так и при обращению к сервису у которого больше одного интерфейса нужно указать нужный.
Если моему Web сервису нужно будет отвечать на различные сообщения я создам сразу несколько URL (interfaces) по которым к сервису можно будет обратиться. Например
https://andreyolegovich.ru:8080 /resource1/status
https://andreyolegovich.ru:8080 /resource1/getserviceInfo
https://andreyolegovich.ru:8080 /resource1/putID
http://andreyolegovich.ru:8080 /resource1/eventslist
https://andreyolegovich.ru:8080 /resource2/putID
…
Как видите у моих эндпойнтов (Enpoints) различные окончания. Такое окончание в Endpoint называются Resource, а начало Base URL.
Такое определение Endpoint и Resource используется, например, в SOAP UI для RESTful интерфейсов
https://andreyolegovich.ru:8080 - это Base URL
/resource1/status - это Resource
Endpoint = Base URL + Resource
Понятие Endpoint может использоваться в более широком смысле. Можно сказать, что какой-то определённый роутер или компьютер является Endpoint. Например, в понятии Endpoint Management под Endpoint имеют в виду конечное устройство. Обычно это понятно из контекста.
Также следует обратить внимание на то, что понятие Endpoint выходит за рамки RESTful и может использовать как в SOAP так и в других протоколах.
Термин Resource также связан с RESTful, но в более широком смысле может означать что-то другое.
На программистском сленге Endpoint иногда называют ручкой.
Сделать какой-то запрос, например HTTP, на сленге будет - дёрнуть ручку
Спецификация
После того все эти интерфейсы созданы, их необходимо описать. Нужен документ из которого будет понятно
- Какие методы можно использовать, посылая запросы на каждый Endpoint
- Должны ли передаваться какие-то данные
- Если нужно передавать данные в теле запроса, то какие
- Какие ответы мы ожидаем в случае успешного запроса
- Какие ответы мы ожидаем когда с запросом или его обработкой на сервере что-то не так
Этот документ должен быть доступен программистам с обеих сторон, иначе они просто не смогут договориться и реализовать работающий Web сервис.
HTTP методы
Вернёмся к первому пункту списка, а именно к тому, что такое методы.
В протоколе HTTP предусмотрено несколько способов отправить запрос на один и тот же Endpoint.
Они называются:
- CONNECT
- DELETE
- GET
- HEAD
- OPTIONS
- PATCH
- POST
- PUT
- TRACE
Про их свойства можно почитать здесь.
Когда мы знаем какие методы с какими Enpoint можно использовать составить запросы не составит труда.
Например:
GET http://andreyolegovich.ru:8080 /resource1/status
GET http://andreyolegovich.ru:8080 /resource1/getserviceInfo
PUT http://andreyolegovich.ru:8080 /resource1/putID
GET http://andreyolegovich.ru:8080 /resource1/eventslist
POST http://andreyolegovich.ru:8080 /resource1/eventslist
PUT http://andreyolegovich.ru:8080 /resource2/putID
…
Таким образом простейший запрос состоит из метода и Enpoint
Request = Method + Endpoint
Пример API
Я заказал бесплатный месяц хостинга у Beget и создал сайт topbicycle.ru , который сообщает всем желающим количество велосипедистов в любом городе.
Чтобы узнать количество велосипедистов в городе нужно отправить GET запрос на https://topbicycle.ru:/bicyclists/$город
GET **https://topbicycle.ru****/bicyclists**/helsinki
Получив такой запрос сайт вернёт число велосипедистов в Хельсинки.
Попробуйте вставить эту строку в браузер.
Доступные города: benalmadena , cordoba , fuengirola , helsinki , malaga ,moscow, spb.
Если хотите немного потренироваться - оцените мои практические уроки по тестированию API - «Уроки тестирование API»
Это очень простые уроки для самых начинающих. Буду рад любым отзывам и предложениям в комментариях.
Calculator. Http methods. Protocols/rfc2616.
Тестирование API без документации
Если Вам по какой-то причине предстоит проделать эту неблагодарную работу, определетесь, насколько всё плохо. Какая у Вас есть информация об объекте тестирования.
Известно ли какие порты для Вас открыты? Знаете ли Вы нужные endpoints?
Сканирование портов
Если дело совсем труба - просканируйте порты, например, с помощью netcat. Открытые порты сохраните в файл openports.txt
nc -z -v answerit.ru 1-10000 2>&1 | grep succeeded > openports.txt
Эта операция займёт довольно много времени. Можете почитать советы по работе с Nmap и Netcat , например, следующие:
Перебор запросов
Если Вам известен нужный порт и соответствующий endopoint переберите все возможные HTTP методы. Начните с наиболее очевидных:
Для ускорения процесса напишите скрипт на Bash или Python .
В худшем случае, когда ни порт ни endpoints неизвестны Вам, скорее всего придётся перебирать все открытые порты и генерировать endpoints, которые подходят по смыслу.
Разработчики обычно не особо заморачиваются и закладывают минимально-необходиму информацию. Так что включите воображение и попробуйте придумать endpoints опираясь на бизнес логику и принятые в Вашей компании стандарты.
Если ни endpoints ни бизнес логика Вам неизвестны, то у меня есть подозрение, что Вы тестируете API с не самыми хорошими намерениями.
Инструменты для тестирования
Существует множество инструментов для тестирования. Здесь Вы можете познакомиться с одними из самых популярных: Python и SOAP UI.
О работе с REST API на Python вы можете прочитать в статье «REST API с Python»
А про то как сделать своё REST API - в статье «Flask»
Web проекты часто тестируются с применением Selenium Webdriver если Вам интересно - посмотрите статью Python + Selenium