Что такое api и как это работает?

Использование в рекламе

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

Например, API «Яндекс.Директа»: с его помощью можно гибко настраивать рекламные кампании, просматривать статистику, создавать приложения, работающие с контекстной рекламой самостоятельно.

• Сервисы поисковых систем для просмотра статистики и вебмастерские панели тоже требуют использования API.
• Если
  перед маркетологом стоит цель продвижения в соцсетях, можно
  интегрировать элементы социальной сети в сайт. Например, демонстрировать
  пользователям сайта записи в официальном сообществе компании в соцсети.
• Для
  сервисов, которые не могут работать без информации с серверов других
  ресурсов (яркий пример – разнообразные агрегаторы), использование API
  незаменимо.

Что такое REST API?

Representable State Transfer(REST) Application Programming Interface(API) предоставляет набор методов, которые программист может использовать через HTTP для отправки и получения данных. Поскольку эти методы используют HTTP, любой язык программирования может работать с ними.

Сейчас доступны тысячи REST API практически на всех возможных сайтах. Обычно для общедоступных данных, таких как погода или фондовые рынки, вы можете найти десятки разных API, доступных для использования. Многие популярные веб-платформы, такие как Facebook и Twitter, также предоставляют API для разработчиков. Некоторые из проприетарных API имеют ограничения на количество обращений к ним. Многие требуют регистрации и получения закрытого ключа. Наиболее безопасные API требуют настройки OAuth для безопасного входа пользователей.

Вы можете найти огромный список публичных API на Github, а еще больший список существует на RapidAPI.

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.

Принцип и использование API Economy

Магический квадрант Gartner для Full Life Cycle API Management, октябрь 2016 г.

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

Но API также создают проблемы. Во-первых, происходит стихийное размножение API, так как каждая компания создает их просто для того, чтобы выглядеть модной (API для саморекламы?). Далее, существует проблема качества. Не всякая компания хорошо поддерживает свои API. Естественно, имеется порядочно вендоров, стремящихся помочь вам управлять всеми этими API (взгляните на магический квадрант Gartner).

Чем же руководствоваться на практике? В нескольких исследовательских заметах Gartner даются следующие подсказки.

• Работа над API должна иметь измеряемую ценность. Не тратьте ресурсы на создание API, которым не воспользуется ни один разработчик.
• Создавайте API только в случае, если у него будет конкретный пользователь. Должны быть партнер или экосистема, которые в нем нуждаются.
• Среднее предприятие всегда использует больше API, чем создает самостоятельно. Его подразделения будут иметь дело с множеством API, и на CIO ложится задача этим управлять.
• API критичны для Интернета вещей, возможностей рядовых пользователей, аналитики и информационных систем. Если, создавая API, вы забываете про эти вещи, хорошенько подумайте.

Принцип API Economy

Использование API открывает новые возможности взаимодействия с экосистемой

API позволяют организациям создавать персонализированное взаимодействие с пользователем

Ожидания и поведение покупателей меняются

Покупатели:

• Требуют индивидуализированного подхода –на их условиях
• Ожидают комплексного интегрированного обслуживания
• Перейдутк любому, кто лучше удовлетворит их требования

Организации:

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

Почему дизайн API так важен

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

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

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

Возможности API MCN Telecom

Возможности API MCN Telecom, в частности, включают:

Управление функциями ВАТС и телефонии через API (и в т. ч. с использованием WebHooks) может включать такие действия, как:

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

и многое другое.

Интеграция ВАТС с CRM позволяет:

• поднимать карточку звонящего клиента при входящем звонке;
• совершать исходящие вызовы из CRM;
• прикреплять записи разговоров к карточкам клиентов в CRM-системе;
• построить воронку продаж, проанализировав в едином приложении данные по звонкам и продажам;
• автоматически направлять звонки клиентов на персонального менеджера с поднятием карточки в CRM;
• синхронизировать телефонный справочник сотрудников компании с внутренними номерами в виртуальной АТС и CRM-системе.

Как воспользоваться API MCN Telecom

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

Чтобы воспользоваться API, нужно произвести настройки в Личном кабинете в разделе API, а также во внешней системе (использующей API MCN Telecom).

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

Документация API с подробным описанием методов доступна в Личном кабинете.

Примеры запросов

Пример ниже показывает пример запроса Callfire API

Дизайн этого сайта API задуман таким образом, что примеры запросов и ответов размещаются в правом столбце страницы. Запрос отформатирован в curl, который мы рассмотрели ранее в разделе Создание curl запроса.

curl — это обычный формат для отображения запросов по нескольким причинам:

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

В общем, чтобы показать пример запроса, используйте curl. Вот еще один пример запроса curl в Parse API:

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

Бывает и так, что сайты документации API могут использовать полный URL-адрес ресурса, например, этот простой пример из Twitter:

URL ресурса включает в себя как базовый путь, так и конечную точку. Проблема с отображением полного URL ресурса состоит в том, что он не указывает, нужно ли передавать какую-либо информацию заголовка для авторизации запроса. (Если ваш API состоит только из запросов GET и не требует авторизации, отлично, но только немногие API настроены таким образом.) Запросы curl могут легко отображать любые параметры заголовка.

Работа с API — реальные примеры использования

Какое практическое применение API может быть? Есть применение, если вы, программист.

Большинство крупных приложений открывают свои API и предоставляют возможность пользоваться ими.

Например, сервис по продвижению крупных технологических проектов под названием Product Hunt, собрал на своем официальном сайте коллекцию API всевозможных сервисов – заходите, скачивайте, пользуйтесь. Тут есть API Gmail, Uber, и так далее.

Кроме того существует интересный ресурс под названием ifttt, который представляет собой максимально доступное для пользователя приложение для работы с различными API. Данный сервис помогает взаимодействовать огромному количеству приложений и сайтов. Например, с помощью этого сервиса можно настроить автоматическую публикацию статей в ленте Facebook после ее публикации на вашем WordPress-сайте.

Принципы REST API

У RESTful есть семь принципов написания кода интерфейсов.

Отделения клиента от сервера (Client-Server). Клиент — это пользовательский интерфейс сайта или приложения, например, поисковая строка видеохостинга. В REST API код запросов остается на стороне клиента, а код для доступа к данным — на стороне сервера. Это упрощает организацию API, позволяет легко переносить пользовательский интерфейс на другую платформу и дает возможность лучше масштабировать серверное хранение данных.

Отсутствие записи состояния клиента (Stateless). Сервер не должен хранить информацию о состоянии (проведенных операций) клиента. Каждый запрос от клиента должен содержать только ту информацию, которая нужна для получения данных от сервера.

Кэшируемость (Casheable). В данных запроса должно быть указано, нужно ли кэшировать данные (сохранять в специальном буфере для частых запросов). Если такое указание есть, клиент получит право обращаться к этому буферу при необходимости.

Единство интерфейса (Uniform Interface). Все данные должны запрашиваться через один URL-адрес стандартными протоколами, например, HTTP. Это упрощает архитектуру сайта или приложения и делает взаимодействие с сервером понятнее.

Многоуровневость системы (Layered System). В RESTful сервера могут располагаться на разных уровнях, при этом каждый сервер взаимодействует только с ближайшими уровнями и не связан запросами с другими.

Предоставление кода по запросу (Code on Demand). Серверы могут отправлять клиенту код (например, скрипт для запуска видео). Так общий код приложения или сайта становится сложнее только при необходимости.

Начало от нуля (Starting with the Null Style).Клиент знает только одну точку входа на сервер. Дальнейшие возможности по взаимодействию обеспечиваются сервером.

API-интерфейсы SOAP являются предшественниками REST API

До того, как REST стал самым популярным веб-сервисом, SOAP (Simple Object Access Protocol) был гораздо более распространенным. Чтобы лучше понять REST, полезно иметь некоторое понимание SOAP. Заодно и увидеть, что отличает SOAP и REST.

SOAP — это стандартизированный протокол, который требует XML в качестве формата сообщений для запросов и ответов. Как стандартный протокол, формат сообщения обычно определяется с помощью файла WSDL (язык описания веб-служб).

Файл WSDL определяет разрешенные элементы и атрибуты в обмениваемых сообщениях. Файл WSDL является машиночитаемым и используется серверами, взаимодействующими друг с другом для облегчения связи.

Сообщения SOAP заключены в «конверт», который включает в себя заголовок и тело, используя определенную схему XML и пространство имен. Пример формата запроса и ответа SOAP см. SOAP против REST 101: понимание различий.

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

SOAP по-прежнему используется в enterprise приложениях (особенно в финансовых учреждениях) со связью server-to-server, но в последние годы SOAP вымещается REST, особенно для API открытых сетей.

Тестовые потоки

Давайте разделим и обозначим три вида потоков тестирования, которые составляют наш план тестирования:

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

2. Многоступенчатый рабочий поток с несколькими запросами — тестирование серии запросов, которые являются обычными действиями пользователя, поскольку одни запросы могут зависеть от других. Например, мы выполняем запрос POST, который создает ресурс и возвращает автоматически сгенерированный идентификатор в своем ответе. Затем мы используем этот идентификатор, чтобы проверить, присутствует ли этот ресурс в списке элементов, полученных запросом GET. Затем мы используем PATCH для обновления новых данных и снова вызываем запрос GET для проверки этого обновления. И в завершении, мы УДАЛЯЕМ этот ресурс и снова используем GET, чтобы убедиться, что записи больше нет.

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

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

Авто генерация примеров кода

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

Paw (на MacOS) позволяет экспортировать запрос практически на все мыслимые языки:

После того, как мы сконфигурировали запрос (процесс похож на Postman), можно сгенерировать фрагмент кода, выбрав Файл> Экспорт запроса.

Приложение Postman также может генерировать фрагменты кода аналогичным образом. Мы рассмотрели этот процесс раннее в разделе Изучение полезных данных JSON ответа. В Postman после конфигурации запроса, кликаем ссылку (которая появляется под кнопкой «Сохранить» в правом верхнем углу).

Затем выбираем нужный язык, например JavaScript> Jquery AJAX:

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

(Для практики, включающей использование сгенерированного кода jQuery из Postman, открываем разделы Изучение полезных данных JSON ответа и Доступ и вывод на страницу определенного значения JSON.)

Сколько весит 1 литр моторного масла?

Отношение массы к объёму масла определяется его плотностью. Но, данный параметр, так же, как и вязкость, будет сильно зависеть от температуры, поэтому чтобы точно перевести литры моторного масла в килограммы необходимо проводить измерение при комнатной температуре. Однако стоит также учесть тот факт, что плотность будет изменятся в зависимости от количества и качества присадок, а если необходимо перевести л/тонн отработанного масла в кг, то плотностные параметры изменятся еще и за счет примесей продуктов износа и нагара (увеличивается на 4 – 6 %).

Для определения какой имеет вес 1 литр масла используется формула плотности: ρ = m / V,где p – плотность (кг/м³); m – масса (килограмм); V – объем (м³).

1 литр масла для двигателя в среднем будет равен 0,850… 0,910 г зависимо от его плотности.

Таблица плотности моторных масел

Плотностный показатель моторной смазки варьируется в диапазоне 0,84 – 0,91 кг/л в зависимости от классификации по SAE и кинематической вязкости (сСт), а к тому же он весьма нестабилен и с увеличением температуры падает.

Плотность синтетических масел большинства производителей в зависимости от вязкости
Класс моторного масла по SAE	Плотность, кг/л
при 20 ⁰С	при 100 ⁰С	при 120 ⁰С
0w40	0,842…0,858	0,766…0,773	0,739…0,743
5w30	0,863…0,868	0,781…0,786	0,762…0,770
5w40	0,867…0,872	0,775…0,781	0,751…0,757
10w30	0,865…0,868	0,801…0,808	0,792…0,800
10w40	0,865…0,870	0,810…0,817	0,801…0,804
15w40	0,910…0,915	0,863…0,871	0,853…0,860
20w50	0,872…0,880	0,835…0,842	0,822..0,831

Плотность полусинтетического моторного масла на 3 — 7 % выше чем у чистой синтетики.

Заметьте, что чем выше температура масла, тем оно легче в том же объеме! А значит, чтоб перевести моторное масло из литров в кг или из килограммов в литры, учтите температуру и используйте поправку если она отличается от эталонного показателя в 20 градусов Цельсия.

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

Коэффициент поправки при изменении на один градус от лабораторного значения, отдельно взятого масла с известной плотностью, будет отличатся и варьироваться от 0, 000867 при плотности 0,739 кг/л до 0,00062 с плотностью 0,915 кг/л.

Коэффициенты поправок плотности

Таблица поправочных коэффициентов плотности при изменении температуры масла
Плотность кг/л при 20⁰С	Температурная поправка на 1⁰С	Плотность кг/л при 20⁰С	Температурная поправка на 1⁰С
0,650-0,659	0,000962	0,8300-0,8399	0,000725
0,660-0,669	0,000949	0,8400-0,8499	0,000712
0,670-0,679	0,000936	0,8500-0,8599	0,000699
0,6800-0,6890	0,000925	0,8600-0,8699	0,000686
0,6900-0,6999	0,000910	0,8700-0,8799	0,000673
0,7000-0,7099	0,000897	0,8800-0,8899	0,000660
0,7100-0,7199	0,000884	0,8900-0,8999	0,000647
0,7200-0,7299	0,000870	0,9000-0,9099	0,000633
0,7300-0,7399	0,000857	0,9100-0,9199	0,000620
0,7400-0,7499	0,000844	0,9200-0,9299	0,000607
0,7500-0,7599	0,000831	0,9300-0,9399	0,000594
0,7600-0,7699	0,000818	0,9400-0,9499	0,000581
0,7700-0,7799	0,000805	0,9500-0,9599	0,000567
0,7800-0,7899	0,000792	0,9600-0,9699	0,000554
0,7900-0,7999	0,000778	0,9700-0,9799	0,000541
0,8000-0,8099	0,000765	0,9800-0,9899	0,000528
0,8100-0,8199	0,000752	0,9900-1,000	0,000515
0,8200-0,8299	0,000738

Почему разработчики его используют

Есть ещё 4 важные причины, по которым разработчики так часто обращаются к api:

1. Программный интерфейс помогает быстрее и проще создавать новые приложения. Зачем изобретать велосипед и колесо, если можно взять разработки товарищей? Скажем, никто не запрещает воспользоваться api нейронной сети TenserFlow для создания своей программы, чтобы не тратить время на разработку собственной системы машинного обучения.
2. Как уже отмечено ранее, апи помогает увеличить безопасность разработки. Интерфейс позволяет перенести важные функции в стороннее приложение, чтобы их невозможно было некорректно использовать. Это решение отлично спасает от человеческого фактора и глупых случайностей.
3. Подключение api позволит проще настраивать связь между различными сервисами и утилитами. Система способна свести к нулю лишнее общение между программистами разных компаний. Это отличная возможность получения нужных функций сторонних приложений, не сотрудничая и даже не общаясь с создателями этих приложений.
4. Готовые интерфейсы помогают не только сохранить время и силы разработчиков, но и деньги, которые не нужно будет тратить на создание важных функций.

Примеры API

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

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

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

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

Google Календарь

Те, кто использовал приложения-календари для iOS или Android, знают, что данные в них можно синхронизировать, подключив один из популярных сервисов: Apple iCal или Google Calendar. Обе компании предлагают разработчикам API, позволяющие подключить свой календарь напрямую к сторонним приложениям. Благодаря подобной интеграции люди могут использовать несколько разных программ со схожей функциональностью и иметь на руках актуальную информацию о всех своих делах.

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

Погодное приложение

Существующие погодные приложения (встроенные в операционную систему или сторонние из App Store или Google Play) получают информацию о погоде из сторонних источников.

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

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

Сервис по заказу авиабилетов

Здесь аналогичная ситуация. Помимо сайтов и приложений, принадлежащих авиакомпаниям, есть так называемые агрегаторы. У нас популярен Aviasales, но есть и другие.

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

Кнопки авторизации

Наверняка вы видели на различных сайтах кнопки, позволяющие зарегистрироваться с помощью уже существующих аккаунтов на популярных площадках. Сейчас такие есть у Google, Facebook, Apple, Twitter, ВКонтакте и т.д. Набор доступных опций на конкретном ресурсе полностью зависит от его хозяев. Это тоже делается через API. Условная Apple создала набор защищенных функций, который можно с минимальными затратами подключить к своему проекту и предоставить пользователям доступ к удобному и безопасному способу авторизации.

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

Навигация на сайтах и в приложениях

Тут почти как с погодой. Есть несколько крупных корпораций, предлагающих картографические данные. Те же Apple, Google, Yandex и парочка других. Некоторые из этих компаний разработали API, позволяющие подключить собственный картографический сервис к другим площадкам. Иногда они используются во внутренних продуктах. Яндекс.Транспорт построен на базе Яндекс.Карт, к примеру. Иногда API используются крупными партнерами. Uber использует для навигации сервис компании Google.

То же самое делают разработчики многих приложений под Android. Так как это API, встроенный в операционную систему, подключить карты Google к своему сервису доставки еды или приложению для бегунов проще всего. На iOS ситуация иная – там проще работать с Apple Maps.

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

10 занятных REST API

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

• PokeAPI. У крупнейшей медиа-франшизы всех времен есть простой способ получить данные о 800+ покемонах.
• NASA API. Получите данные об астероидах, галактиках и многом другом.
• Open Food Facts. Огромное количество данных о продуктах питания со всего мира.
• TransLoc OpenAPI. Получите живые данные об общественном транспорте городов и кампусов.
• Urban Dictionary API. Удивительно, какой сленг используют люди!
• Merriam-Webster Dictionary API. Для тех, кому нужны определения и синонимы реальных слов.
• Numbers API. Интересные факты и вопросы о числах.
• WeatherBit API. Текущие и исторические данные о погоде.
• US Government Data API. Достаточно большой набор данных о Соединенных Штатах — сельское хозяйство, здравоохранение, общественная безопасность и т.д.
• Bible API. Самая продаваемая книга всех времен. Величайшая история.

Типы

Api различаются по виду предоставления доступа:

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

Так же существуют следующие три вида web api, необходимые для разработки http-служб:

• RPC (Remote Procedure Call), который использовали раньше, когда все компьютерные системы были связаны между собой исключительно по локальной связи. Процесс вызова удаленных систем сильно напоминал вызов функций в утилитах. Как примеры этой системы можно вспомнить CORBA и DCOM;
• SOAP (Simple Object Access Protocol) отлично взаимодействует с протоколами прикладного уровня и позволяет обмениваться сообщениями в распределительной вычислительной среде. Умеет не только удаленно вызывать необходимые процедуры, но и рассылать и принимать сообщения в формате XML;
• REST (Representational State Transfer) был создан как архитектура программного обеспечения для веб-служб. Он работает с самими разными форматами: с сайтами, с flash-программами и так далее. Api требует значительно меньше вычислительных ресурсов, так все данные отправляются без дополнительных слоев, следовательно, все передачи тратят значительно меньше ресурсов.

Что будет, если API отключится или поменяются условия

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

Раньше было так: есть открытый API для карт, им можно было пользоваться почти без ограничений — 750 000 бесплатных запросов, этого хватало почти для каждой компании. Программист просто формировал специальный код для вставки на сайт, который обращался к серверу Гугла и получал в ответ нужный кусок карты со всеми функциями. Получается, что в каждом таком сайте была встроена мини-версия сервиса Google Maps.

Потом всё поменялось: Гугл изменили правила использования своего API для карт, и теперь есть ограничения на количество показов и запросов к сервису. Теперь бесплатно можно запросить карты только 28 000 раз. Это значит, что если у вас есть сайт с картой, которую вы загружаете по API, то первые 28 000 посетителей сайта увидят это бесплатно, а за каждый новый показ вам, как владельцу сайта, придётся заплатить.

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

Размещаем эти запросы на flask.

Рекоммендуется использовать стандартную структуру страниц.

В api.py расположим основной обработчик страниц. Для обработки post-запроса с json-ом и примером формы. Для валидации самым лаконичным решением будет pydantic,из которого потребуется BaseModel, ValidationError, validator

Если потребуется styles.css то располагаться ему следует в /static/css.

Стандартное место расположения шаблонов страниц — /templates. Base.html для наследования общего стиля.

Форму регистрации сделаем например в таком виде

После чего мы можем например отправлять post-запросы к нашему сервису, таким же образом, curl-ом, через postman или руками заполняя формы на веб-странице.

Стратегия тестирования API

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

Основными задачами функционального тестирования API являются: 

убедиться, что реализация API работает правильно, как и ожидалось — без ошибок!

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

предотвратить регрессий между написанным кодом(merge) и релизом.

CWE-352 Cross-Site Request Forgery (CSRF) (Межсайтовая подмена запросов)

• На сервере реализовать механизм «CSRF токенов». Это такой механизм, когда для каждой сессии пользователя генерируется новый токен и сервер проверяет его валидность при любых запросах с клиента.
• На сервере проверять заголовки Origin и Referer, в которых содержится адрес источника запроса. Но эти заголовки могут отсутствовать.
• Также можно всегда требовать от пользователя подтверждать критические действия вводом пароля или вторым фактором аутентификации, но возможность таких мер зависит от бизнеса.
• При создании Cookies выставлять параметр SameSite, но этот механизм поддерживают не все браузеры.

Как работает API?

Теперь, когда мы установили, что API — это набор процедур, которые указывают программное обеспечение в правильном направлении, как именно это все работает?

Лучший способ объяснить основные функциональные возможности API — это привести пример из реальной жизни. Службы доставки еды, такие как GrubHub , сейчас невероятно популярны, поэтому давайте обсудим, как может работать код таких мобильных приложений.

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

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

API — это связь между этой базой данных и веб-сайтом или приложением, которое представляет свои данные

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

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

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