Что такое api? простое объяснение для начинающих

API

API (Application Programming Interface – программный интерфейс приложений) – технология взаимодействия программных систем (обмена данными). API, предоставляемые программными продуктами компании MCN Telecom, дают возможность различным сторонним бизнес-приложениям обмениваться с ними данными и управлять их функциями. Интеграция бизнес-приложений с виртуальной АТС, телефонией и другими продуктами компании MCN Telecom с применением API позволяет автоматизировать бизнес-процессы, использовать единый интерфейс, эффективно организовать работу сотрудников и подразделений компании. 

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

Технология WebHooks – разновидность API, в которой передача сообщений инициируется системой, предоставляющей API, т. е. о событиях в ней внешние системы получают уведомления моментально.

Другим вариантом является передача данных, инициируемая из внешней).

Действия, запущенные через API, приложениями MCN Telecom выполняются и тарифицируются обычным образом – точно так же, как и инициированные другими способами. Например, звонки, выполненные по API, для телефонной сети неотличимы от звонков с обычного телефона, и тарифицируются по той же цене.

Каковы преимущества использования API?

API-интерфейсы – это, по сути, набор правил. Они могут улучшить внутренние процессы разработки организации за счет стандартизации того, как разработчики пишут код приложения – использование одних и тех же правил и форматов делает код более оптимизированным и прозрачным. Стандартизация также облегчает сотрудничество между разработчиками при создании программных компонентов с целью интеграции с API. Это, в свою очередь, может поддержать разработку функций и сократить время вывода продукта на рынок.

Публичные и партнерские API дают организациям:

• Безопасный контроль и управление доступом пользователей и систем к определенным данным и функциям услуг;
• Возможность позволять третьим сторонам использовать свои данные (даже в ограниченном смысле), что увеличивает узнаваемость бренда компании;
• Расширять свою клиентскую базу данных и даже повышать коэффициент конверсии, согласовывая свои услуги с услугами других надежных брендов;
• Монетизировать свои API, чтобы они стали отдельной статьей дохода. Это обычная тактика для онлайн-платежных шлюзов – например, компании, использующие API PayPal, готовы платить за возможность использовать надежную платежную систему.

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

API7:2019 Security Misconfiguration (Некорректная настройка параметров безопасности)

• Используются дефолтные настройки приложений, которые могут быть небезопасны.
• Используются открытые хранилища данных.
• В OpenSourсe попала закрытая информация, например, конфигурация системы или параметры доступа.
• Неправильно сконфигурированы HTTP заголовки (данная тема рассмотрена далее в разделе «Insecure HTTP Headers»).
• Аутентификационные данные (логин/пароль, токен, apiKey) посылаются в URL. Это небезопасно, т.к. параметры из URL могут оставаться в логах веб серверов.
• Отсутствует или неправильно используется политика Cross-Origin Resource Sharing (CORS) (данная политика рассмотрена далее в одноимённом разделе).
• Не используется HTTPS (использование HTTPS рассмотрено в разделе «Insecure Transport»).
• При эксплуатации промышленной системы используются настройки, предназначенные для разработки и отладки.
• Сообщения об ошибках содержат чувствительную информацию, например, трейсы стека.

• Для пользователей устанавливать только необходимые права доступа.
• Открывать только необходимые сетевые порты.
• Устанавливать безопасные версии патчей OS и приложений (подробно рекомендации рассмотрены в разделе «Using Components with Known Vulnerabilities»).

API Explorer может быть опасным в руках пользователя

Хотя интерактивность является мощным средством, API Explorer может быть опасным дополнением к вашему сайту. Что, если начинающий пользователь, который пробует метод DELETE, случайно удалит данные? Как мы позже удалим тестовые данные, добавленные методами POST или PUT?

Одно дело разрешить методы GET, но если включить другие методы, пользователи могут случайно повредить свои данные. В API Sendgrid появляется предупреждающее сообщение для пользователей перед проверкой вызовов с помощью их API Explorer:

Документация API Foursquare раньше имела встроенный API Explorer в предыдущей версии своих документов (см. Ниже), но позже его удалили. Возможно, они столкнулись с некоторыми из этих проблем.

Что касается интеграции пользовательских инструментов API Explorer, эта задача должна быть относительно простой для разработчиков. Все, что делает API Explorer, это отображает значения из поля в вызов API и возвращает ответ в тот же интерфейс. Другими словами, API-интерфейс — это все, что нужно, плюс немного понимания JavaScript и навыков фронтенда, для успешной работы.

Не обязательно создавать свои собственные инструменты. Существующие инструменты, такие как Swagger UI (который анализирует спецификацию OpenAPI) и Readme.io (который позволяет вводить детали вручную или из спецификации OpenAPI), могут интегрировать функционал API Explorer непосредственно в документацию.

Note: Пособие по созданию собственного API Explorer см. В Руководство Swagger UI.

Публикация и управление API

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

Тестирование API

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

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

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

Управление API

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

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

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

Почему не нужно бояться API

Как сервис с сотней тысяч клиентов мы каждый день сталкиваемся с проблемой — SEO-специалисты боятся работать с API либо не видят преимуществ. Только прогрессивные агентства по интернет-маркетингу и крупный бизнес выбирают работу с API. Основная причина этому — обработка полученных данных, так как они выгружаются в формате JSON и выглядят вот так:

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

Поэтому наши специалисты создали , обрабатывающий данные из поисковой аналитики Serpstat вместо вас. Это бесплатно, и воспользоваться может любой пользователь сервиса. Ниже описана инструкция по настройке скрипта и даны еще пять других бесплатных скриптов.

Что было до API?

API существовал не всегда. Его появление на рынке стало технологической революцией и внесло много изменений в онлайн мир.

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

В чем была проблема?

Этот контент мог бы быть идеальным, но сопровождался риском стать устаревшим и содержать недействительные ссылки.

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

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

Как API используются в контексте всемирной паутины?

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

Пример того, как используется API:

Знаете, почему вы можете быстро зарегистрироваться в разных приложениях, используя только аккаунт Facebook?

Это происходит благодаря специальному API Facebook. Компании используют код и API для предоставления клиентам быстрого и простого доступа к их платформам.

Что будет, если не использовать API?

Если вы решите не использовать API, приложение может, например, узнать о новой статье Академии Mobidea открыв www.academy.mobidea.com

Затем приложение прочтет веб страницу, как если бы оно было человеком, и интерпретирует контент страницы, в данном случае – Академии.

Та же ситуация с использованием API: приложение находит информацию о веб странице www.academy.mobidea.com , отправив сообщение на API Академии Mobidea.

Сообщение отправляется в формате JSON.

Что такое формат JSON?

Формат JSON (JavaScript Object Notation) это файл открытого стандарта, содержащий объекты данных и соответствующие атрибуты.

Например, когда мы проверяем новые статьи в Академии Mobidea, передаваемый JSON файл выглядел бы так:

article {

title: “Новая статья”,

date: 01/01/2017,

content: “Много текста.”,

author: “Джон Уайт”

}

Далее, после отправки сообщения в формате JSON, API страницы www.academy.mobidea.com реагирует структурированным ответом, похожим на пример выше.

Почему метод передачи информации так важен?

Вот почему: когда вы используете API, веб страница документирует определенную структуру ответа и запроса.

Это значит, что информация остается неизменной, вне зависимости от того, меняет ли веб страница свой внешний вид и дизайн или нет.

Без API приложение определенно должно полагаться на неточный факт, что вебсайт не изменит свой внешний вид.

Что случится, если сайт поменяется, и при этом API не был использован?

Скорее всего приложение перестанет работать!

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

Оно просто не сможет понять данные, передаваемые с данного вебсайта.

Advertisement

В итоге, API это более безопасный и надежный вариант.

С ним вы можете быть уверены в том, что приложение продолжит работать с сайтом.

Не имеет значения, если сайт вдруг решил изменить дизайн или структуру – API прочтет его в любом случае.

API как соглашение — сначала проверьте спецификацию!

API — это, по сути, соглашение между клиентом и сервером или между двумя приложениями

Перед тем, как начать любое тестирование функциональности, важно убедиться в правильности соглашения. Это можно сделать сначала проверив спецификацию (или само соглашение службы, например, интерфейс Swagger или ссылку OpenAPI) и убедившись, что:

• эндпоинты правильно именованы;

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

• нет отсутствующей или дублирующей функциональности;

• отношения между ресурсами правильно отражаются в API.

Приведенные выше рекомендации применимы к любому API, но для простоты в этом посте мы предполагаем наиболее широко используемую архитектуру веб-API — REST через HTTP

Если ваш API спроектирован именно как RESTful API, важно убедиться, что контракт REST действителен, включая всю семантику, соглашения и принципы HTTP REST. (описание тут, тут, и здесь)

Если у вас общедоступный API, ориентированный на клиента, такое тестирование может быть вашим последним шансом убедиться, что все требования соглашения выполнены. После публикации и использования API любые внесенные вами изменения могут внести ошибки в код клиента.(Конечно, когда-нибудь вы сможете опубликовать новую версию API (например, /api/v2 /), но даже в этом случае обратная совместимость скорее всего будет обязательной).

REST он же RESTful веб-API

Вырываемся за границы сервера и уютного терминала. Пробираемся поближе к массовым интерфейсам — браузерам и им подобным приложениям. Туда, где в основе взаимодействия систем используются гипертекстовые протоколы семейства http. В IRIS «из коробки» для этого работает связка из собственно сервера баз данных и http-сервера Apache.

В нашем примере основой идентификатором будет что-то вроде основы из адреса сервера IRIS http://localhost:52773 и приставленного к нему пути до наших данных /world/ или более конкретно по стране /world/France.

Примерно так в докер-контейнере:

http://localhost:52773/world/France

При разработке полноценного приложения в документации IRIS рекомендуется воспользоваться одним из трёх генераторов кода. Например, один из них основан на описании REST API по спецификации OpenAPI 2.0.

Мы пойдём простым путём — реализуем API вручную. В нашем примере сделаем простейшее REST-решение, которое требует всего два шага в IRIS:

1. Создать класс-диспетчер путей в URL, который будет унаследован от системного класса %CSP.REST

2. Добавить обращение к нашему классу-диспетчеру при настройке веб-приложения IRIS

Шаг 1 Класс-диспетчер

Реализация класса должна быть достаточно понятна. Делаем по инструкции в документации для «ручного» REST:

И внутри добавляем метод-обработчик ровно так же, как были устроены вызовы в терминале из предыдущего примера:

Как можете видеть, для передачи из входящего REST-запроса в параметра name вызываемого метода-обработчика в диспетчере указывается параметр с двоеточием в начале «:name».

Шаг 2 Настройка веб-приложения IRIS

В меню System Administration > Security > Applications > Web Applications

добавляем новое веб-приложение с указанием точки входа по URL на /world и обработчик — наш класс-диспетчер worldrest.

Избегайте неатомарных операций

С применением массива изменений часто возникает вопрос: что делать, если часть изменений удалось применить, а часть — нет? Здесь правило очень простое: если вы можете обеспечить атомарность, т.е. выполнить либо все изменения сразу, либо ни одно из них — сделайте это.

Плохо:

— клиент никак не может узнать, что операция, которую он посчитал ошибочной, на самом деле частично применена. Даже если индицировать это в ответе, у клиента нет способа понять — значение объёма лунго изменилось вследствие запроса, или это конкурирующее изменение, выполненное другим клиентом.

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

Лучше:

Здесь:

• — уникальный идентификатор каждого атомарного изменения;

• — время проведения каждого изменения;

• — информация по ошибке для каждого изменения, если она возникла.

Не лишним будет также:

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

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

Неатомарные изменения нежелательны ещё и потому, что вносят неопределённость в понятие идемпотентности, даже если каждое вложенное изменение идемпотентно. Рассмотрим такой пример:

Допустим, клиент не смог получить ответ и повторил запрос с тем же токеном идемпотентности.

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

Более корректно было бы при получении повторного запроса с тем же токеном ничего не делать и возвращать ту же разбивку ошибок, что была дана на первый запрос — но для этого придётся её каким-то образом хранить в истории изменений.

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

Популярные API

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

• Facebook API позволяет логиниться на сторонних платформах с помощью своего аккаунта, оплачивать покупки в приложении, получать доступ к данным крупных и средних аккаунтов Instagram Business, управлять страницами сообществ и публиковать на них контент, получать статистику по рекламе, управлять объявлениями и аудиторией, запускать прямые эфиры,
• С помощью Twitter API можно показывать ленту твитов на сайте, управлять профилем и настройками учетной записи, автоматически создавать рекламные кампании в Твиттере и управлять ими,
• API ВКонтакте дает возможность отслеживать активность пользователей в сообществах, создавать ботов, собирать статистику по действиям в сообществе, автоматически модерировать контент, автоматизировать работу с товарами (например, импорт из внешней базы), получать текстовые публикации из ВКонтакте по заданным ключевым словам и т.д.,
• Telegram Bot API представляет собой HTTP-интерфейс для работы с ботами в Telegram,
• YouTube API позволяет встраивать видео на сайт, создавать плейлисты, встраивать плеер в приложение, получать данные об активности пользователей.

Не менее популярны и следующие API:

Яндекс API – у всех популярных сервисов Яндекса есть свои API (Вебмастер, Метрика, Директ, Маркет, Аудитории, Карты и т.д.), благодаря которым можно:

• получать информацию о товарах, представленных на Маркете и создавать приложения для автоматизированного размещения,
• автоматизировать создание счётчиков Метрики, настройку целей и получение статистики,
• создавать приложения для управления рекламными кампаниями, автоматизировать процесс создания рекламных кампаний и управлять ими через интерфейс собственного приложения,
• настраивать разнообразные аудиторные сегменты, которые можно использовать для показа рекламных объявлений,
• использовать картографические данные,
• размещать на сайте или в приложении расписания поездов, электричек, самолетов,
• автоматизировать создание и отправку заказов на доставку,
• встроить Яндекс.Переводчик в мобильное приложение или веб-сервис для конечных пользователей,
• автоматизировать проверку семантической разметки и т.д.

Google API

• Работа с устройствами и приложениями на платформе Android,
• Управление событиями в Календаре,
• Управление товарами и акккаунтом в Google Покупках,
• Управление файлами на Google Диске, включая загрузку, скачивание, поиск, изменение прав доступа,
• Просмотр и управление данными Google Analytics,
• Чтение и редактирование файлов в Документах,

SDK представляют инструменты для API

Часто разработчики создают , который сопровождает REST API. SDK помогает разработчикам реализовать API с помощью специальных инструментов. API не зависят от языка, SDK зависит от языка.

Например, в одной компании был и REST API, и JavaScript SDK. Поскольку JavaScript был целевым языком, над которым работали разработчики, компания разработала SDK JavaScript, чтобы упростить работу с REST с использованием JavaScript. Стало возможным отправлять вызовы REST через JavaScript SDK, передавая ряд параметров, относящихся к веб-дизайнерам.

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

Тенденции API

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

REST и Web

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

И REST, и SOAP могут вызывать облачные сервисы, подключаться к ним и взаимодействовать с ними, но REST все чаще предпочтительнее для веб-API, поскольку он использует меньшую пропускную способность и предлагает больше возможностей для языков программирования, таких как JavaScript или Python. Крупные веб-сайты, такие как Amazon, Google, LinkedIn и Twitter, используют RESTful API.

API и облако

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

Эти облачные возможности сместили фокус API-интерфейсов с простых моделей, ориентированных на RPC-программиста, на веб-модели RESTful и даже на то, что называется «функциональным программированием» или «лямбда-моделями» сервисов, которые можно мгновенно масштабировать по мере необходимости в облако.

API как сервисы

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

SOA и микросервисы являются примерами сервисных API. Сервисы – самая горячая тенденция в API, до такой степени, что возможно, что все API в будущем будут рассматриваться как представляющие сервисы.

Какие функций могут входить в API

У разработчиков нет каких-то строгих инструкций или ограничений в выборе функций для api. Поэтому создатели добавляют в программный интерфейс всё то, что позволит конечным потребителям использовать максимум полезных возможностей программы.

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

Кроме того, api могут использовать не только для работы и решения вопросов в приложениях, а ещё и для рекламного продвижения. К примеру, никто не запретит предоставить доступ к программному интерфейсу, представив это как отдельную услугу.

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

Скажем, api YouTube позволяет вставлять видеоролики прямо на свой сайт или страницу в, api платежных систем даст возможность вашим клиентам оплачивать товар или услугу прямо у вас на страничке, а api метеопортала, встроенный на ваш портал, покажет текущие погодные условия.

Ряд корпораций предоставляют свои api как отдельный сервис. Представим, что вам нужно использовать интерактивную карту на портале вашего онлайн-магазина, чтобы клиент мог построить маршрут до ближайшего к нему открытого филиала магазина. В таком случае вам поможет установка и настройка api Яндекс.Карт.

Пример API и тестовая матрица

Теперь мы можем отобразить все в виде матрицы и использовать ее для написания подробного плана тестирования (для автоматизации тестирования или ручных тестов).

Предположим, что подмножеством нашего API является конечная точка /users, которая включает следующие вызовы API:

Вызов API	Действие
GET /users	Просмотреть всех пользователей
GET /users?name={username}	Получить пользователя по имени пользователя
GET /users/{id}	Получить пользователя по ID
GET /users/{id}/configurations	Получите все конфигурации для пользователя
POST /users/{id}/configurations	Создать новую конфигурацию для пользователя
DELETE /users/{id}/configurations/{id}	Удалить конфигурацию для пользователя
PATCH /users/{id}/configuration/{id}	Обновить конфигурацию для пользователя

Где {id} — это UUID, а все конечные точки GET позволяют фильтровать, сортировать, исключать и ограничивать дополнительные параметры запроса для фильтрации, сортировки и разбивки на страницы тела ответа.

Основные позитивные тесты (позитивный путь по умолчанию)Позитивные тесты + необязательные параметры проверокНегативное тестирование – валидный ввод данныхНегативное тестирование — неверные входные данныеДеструктивное тестирование

Тест-кейсы, полученные из приведенной выше таблицы, должны охватывать различные потоки тестирования в соответствии с нашими потребностями, ресурсами и приоритетами (перевод таблицы в формате xls).

Выходим за рамки функционального тестирования

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

Уровни зрелости API

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

Безопасность и авторизация

• Убедитесь, что API разработан в соответствии с правильными принципами безопасности: отказ по умолчанию, безопасное падение сервиса, принцип наименьших привилегий, отклонение всех невалидных данных в запросе и т. д.

  • Позитивные тесты: убедитесь, что API отвечает на правильную авторизацию всеми согласованными методами аутентификации — ответный токен auth 2.0, файлы cookie, дайджест и т. д. — как определено в вашей спецификации.

  • Негативные тесты: убедитесь, что API отклоняет все несанкционированные вызовы.

Ролевые доступы: убедитесь, что определенные конечные точки доступны пользователю в зависимости от роли. API должен отклонять вызовы конечных точек, которые не разрешены для роли пользователя.

Проверка протокола: проверьте HTTP / HTTPS в соответствии со спецификацией

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

Политики ограничения скорости, троттлинга и политики контроля доступа

Нагрузочные тесты (позитивные), стресс-тесты (негативные)

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

API, использующие протокол HTTP = веб-сервисы

«Веб-сервис» — это веб-приложение, предоставляющее ресурсы в формате, используемом другими компьютерами. Веб-сервисы включают в себя различные типы API, в том числе REST и SOAP API. Веб-сервисы — это, в основном, запросы и ответы между клиентами и серверами (компьютер запрашивает ресурс, а веб-сервис отвечает на запрос).

API, использующие протокол HTTP для передачи запросов и ответов, рассматриваются как «веб-сервисы». В случае веб-сервисов клиент, делающий запрос на ресурс, и сервер API, предоставляющий ответ, могут использовать любой язык программирования или платформу. Не имеет значения, какой ЯП или платформа будут использоваться, потому что запрос сообщения и ответ сделаны через общий веб-протокол HTTP.

Веб-протокол является частью прекрасного веб-сервисов: они независимы от языка и поэтому совместимы между различными платформами и системами. При документировании REST API не имеет значения, строят ли инженеры API с помощью Java, Ruby, Python или какого-либо другого языка. Запросы выполняются через HTTP, и ответы возвращаются через HTTP.

Диаграмма ниже показывает общую модель REST API:

Как видно, между клиентом и сервером API существует запрос и ответ. Клиент и сервер могут быть основаны на любом языке, но HTTP — это протокол, используемый для передачи сообщения. Этот шаблон запроса и ответа, по сути, является принципом работы API REST.

Любой язык программирования, создающий запрос, будет по-своему отправлять веб-запрос и анализировать ответ на своем языке. Эти специфичные для языка функции отправки запросов и анализа ответов не являются частью REST API (хотя они могут быть предоставлены в прилагаемом SDK). REST API не зависит от языка и обрабатывает входящую и исходящую информацию по HTTP.