Rest api и api в чем разница

REST API: что это такое простыми словами, примеры запросов, варианты использования сервиса, методы

В этой статье мы разберем оболочку REST API, расскажем, что это такое простыми словами, как работает система.

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

Что такое REST API

Это английская аббревиатура, которая расшифровывается и переводится как передача состояния представления. Web-службы, которые пользуются системой Representational State Transfer, применяют термин RESTful. Отличие этого архитектурного стиля от других состоит в том, что у него нет единого стандарта, однако при этом допустимо использовать XML, HTTP, JSON и URL.

Representational State Transfer разработали еще в 2000 году, но с того момента он очень развился и сейчас стал одним из самых популярных, отодвинув на задний план аналогичные.

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

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

В качестве примера стоит привести кнопку Facebook, которая умеет задействовать соцсеть, или видео на Youtube, его тоже запускает веб-версия API.

Как работает

В первую очередь стоит разобраться, как действует подход:

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

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

Что такое API

По сути, это интерфейс программирования, который обладает следующими признаками:

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

В его задачи входит представлять состояние передачи:

Протокол по типу концентрированного REST API, работающий по HTTP равно качественным веб-сервисам

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

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

Это вообще лучшая часть всего созданного в компьютерном мире. Так как подобные веб-сервисы не зависят от языков, то могут совмещаться с самыми разными системами. Когда API документируется, то неважно, чем пользовались разработчики при его создании — Ruby это был, Java или Python или что-то принципиально другое. Все запросы высылаются через один и тот же HTTP, решения приходят таким же способом.

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

SOAP стоит отнести к предкам интерфейсов по типу REST API

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

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

Все сообщения внутри SOAP собираются в своеобразные «конвертики», в которых есть заголовок и основное тело. Все это «пакуется» при помощи заранее сформированной схемы по принципу XML.

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

Источник

REST API: минимум, который нужно знать новичку

Что такое программный интерфейс приложения (API)

Перед тем, как начать разговор о REST API, давайте вспомним, что такое API и для чего он нужен. API расшифровывается как Application Program Interface — программный интерфейс приложения. Данное понятие применимо не только к веб-разработке, но и к любым программным продуктам вообще. Наушники, микроволновые печи, телевизоры, микропроцессоры — все они имеют свой API.

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

REST API — частный случай API

Допустим, мы написали сайт на PHP (Python, Java — не принципиально). PHP генерирует контент на сервере и по сети нам отправляет обратно уже сгенерированный HTML, JavaScript и CSS. Создавая сайт на PHP, вы получили некую статику, напрямую связывая код PHP, стили, HTML. Он взаимодействует с базой данных и выводит данные в шаблон. Предположим, мы задались целью разработать мобильное приложение под данную систему. Мобильное приложение должно работать с той же базой данных и мы должны как-то присоединить его к уже существующей системе.

Раньше многие шли по такому пути — создавали API для системы «сайт плюс база данных», и мобильное приложение работало через API или непосредственно через сам сайт. Но поддерживать и расширять такую концепцию было неудобно, поэтому постепенно перешли к варианту, когда используется связка backend и frontend. Backend по-прежнему работает с базой данных, а frontend является вообще отдельным приложением, которое, грубо говоря, ничего не знает про backend. Frontend является абстрагированный клиентом и может быть написан на Angular, React, Vue или просто на JavaScript.

Если для сайта имеется мобильное приложение, оно также относится к разряду клиентов и общается с backend-частью посредством API. При такой схеме клиентов может быть сколько угодно — мобильный клиент для Android, приложение под iOS, десктопное приложение, админка сайта и т. д. Частным случаем такой организации является REST API (Representational State Transfer) — некий стандартизированный протокол, позволяющий перемещать state и обмениваться им по API. Впервые его описал в своей диссертации Рой Филдинг. В ней он предложил соединять разные части программы либо сервисы по HTTP.

Критерии RESTful-приложения

Rest — это обычный запрос клиент-сервер с использованием HTTP протокола. В роли клиента не обязательно выступает браузер, это может быть мобильное приложение, десктопное приложение или же другой веб-сайт. В качестве ответа сервер выдает не привычную html-страницу, а просто набор данных, оформленных в том или ином формате. Чаще всего это JSON или XML. Неразрывно с REST следует AJAX (Asynchronous Javascript and XML).

Речь идет об отправке с браузера асинхронных запросов к серверу с помощью JavaScript. XML в данном случае не актуален, а процесс асинхронного общения браузера и веб-сервера задается именно REST-правилами. Веб-сервисы, которые полностью соответствуют парадигме Representational State Transfer, обычно называются RESTful. Чтобы приложение было RESTful, оно должно удовлетворять следующим правилам:

SOAP API — стандарт–предшественник REST API

Хотя на REST API и накладываются эти ограничения, он считается более простым в использовании, чем предшествующий ему протокол SOAP (простой протокол доступа к объектам). Последний выдвигает определенные требования, такие как обмен сообщениями XML, а также встроенные средства безопасности и соответствия транзакциям, что делает его медленнее и тяжеловеснее.

При отправке запроса данных в SOAP API, данные могут обрабатываться через любой из протоколов прикладного уровня: HTTP (для веб-браузеров), SMTP (для электронной почты), TCP и прочие. SOAP использует HTTP как транспортный протокол, в то время как REST базируется на нем. Как только запрос получен, возвращаемые сообщения SOAP должны быть переданы в виде XML-документов — языка разметки, который может считываться как человеком, так и машиной. Завершенный запрос к SOAP API не кэшируется браузером, поэтому он не может быть доступен вторично без повторной отправки в API. На данный момент SOAP — это устаревший стандарт, тем не менее довольно часто используемый enterprise-системами.

Типы запросов

Благодаря тому, что REST API построен поверх HTTP, не важно на каком языке написан frontend (JavaScript или Swift) и backend (Python, Java, C# и пр.), все они смогут взаимодействовать с данным протоколом. Каждый ресурс в REST должен быть идентифицирован посредством стабильного идентификатора, который не меняется при изменении состояния ресурса. Идентификатором в REST является URI. При помощи URL REST API сервер понимает с какими объектами работает, какие объекты ему нужно получить и какие объекты следует удалить.

REST API активно использует методы HTTP протокола и его статуса. В нем присутствуют несколько основных типов запросов:

Если мы говорим о REST как о бизнес-логике, то у нас есть объект и мы передаем статус этого объекта. Например, у нас есть сайт пиццерии и новый заказ. Мы можем заказ создать, узнать о нем подробности, можем обновить его или удалить. И чаще всего для этого используется формат JSON.

Коды запросов

Структура запроса включает в себя маршрут запроса, тип метода, заголовки и тело сообщения. Каждый запрос REST API сопровождается цифровыми кодами. Такие коды называются HTTP-статусами. Они сообщают об успешности запроса.

Статусы разделены на пять групп по своему значению:

Например, редактирование записи на сервере может выполнено успешно (код 200), может быть заблокировано контролем безопасности (код 401 или 403), или не пройти вообще из-за ошибки сервера (код 500).

Чтобы работать с REST API сервисами можно использовать такие инструменты как Postman, SOAP UI (open source утилита по работе с сервисами) и Curl — утилита командной строки, присутствует почти на всех Linux-компьютерах.

Недостатки REST API

Минус этого архитектурного стиля состоит в том, что он завязан на HTTP. Спецификация HTML имеет ограничения и формы, отправляющие данные могут быть реализованы только через GET или POST. Поэтому для корректной работы с другими методами их приходится имитировать. Например, в Rack (механизм на базе которого Ruby взаимодействует с веб-сервером; с использованием Rack сделаны Rails, Merb и прочие Ruby-фреймворки) в форму можно прописать hidden-поле с именем “_method”, а в качестве значения указать имя метода (скажем, «PUT») — при этом будет отправлен POST-запрос, но Rack сможет сделать вид, что получил PUT, а не POST.

Заключение

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

Недостатком REST API является то, что он опирается на спецификацию HTTP-протокола. Сам по себе REST API не является стандартом, это архитектурный подход. Из этого следует, что он может сильно отличаться у разных компаний. REST удобно использовать в простых случаях и когда важна скорость работы — при работе с мобильным устройством, с JavaScript. В сложных случаях, когда критична поддержка валидации, транзакции — используется SOAP. Помимо REST API имеются и иные способы создания API-систем, такие как JSON-RPC, XML-RPC и GraphQL. Однако на данный момент архитектурный стиль REST API остается самым популярным.

Детальное описание всех кодов REST-запросов (справочник) можно найти здесь — https://restapitutorial.ru/httpstatuscodes.html

Подробнее о REST-проектах, построенных с применением данного архитектурного стиля, а также их отличиях от SOAP сервисов можно узнать из видео ниже:

Источник

Введение в REST API — RESTful веб-сервисы

Эта статья начинает серию постов о разработке REST API:

Intro to RESTful Web Services

REST означает REpresentational State Transfer (Википедия: «передача состояния представления»). Это популярный архитектурный подход для создания API в современном мире.

Вы изучите:

Что такое REST?

REST расшифровывается как REpresentational State Transfer. Это был термин, первоначально введен Роем Филдингом (Roy Fielding), который также был одним из создателей протокола HTTP. Отличительной особенностью сервисов REST является то, что они позволяют наилучшим образом использовать протокол HTTP. Теперь давайте кратко рассмотрим HTTP.

Краткий обзор HTTP

Давайте сначала откроем браузер и зайдем на веб-страницу:

А затем щелкните на одной из страниц результатов:

Далее мы можем нажать на ссылку на странице, на которой мы оказались:

И перейти на другую страницу:

Вот как мы обычно просматриваем веб страницы.

Когда мы просматриваем страницы в Интернете, за кулисами происходит много вещей. Ниже приведено упрощенное представление о том, что происходит между браузером и серверами, работающими на посещаемых веб-сайтах:

Протокол HTTP

Когда вы вводите в браузере URL-адрес, например www.google.com, на сервер отправляется запрос на веб-сайт, идентифицированный URL-адресом.
Затем этот сервер формирует и выдает ответ. Важным является формат этих запросов и ответов. Эти форматы определяются протоколом HTTP — Hyper Text Transfer Protocol.

Когда вы набираете URL в браузере, он отправляет запрос GET на указанный сервер. Затем сервер отвечает HTTP-ответом, который содержит данные в формате HTML — Hyper Text Markup Language. Затем браузер получает этот HTML-код и отображает его на экране.

Допустим, вы заполняете форму, присутствующую на веб-странице, со списком элементов. В таком случае, когда вы нажимаете кнопку «Submit» (Отправить), HTTP-запрос POST отправляется на сервер.

HTTP и RESTful веб-сервисы

HTTP обеспечивает базовый уровень для создания веб-сервисов. Поэтому важно понимать HTTP. Вот несколько ключевых абстракций.

Ресурс

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

URI ресурса

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

REST и Ресурсы

Важно отметить, что с REST вам нужно думать о приложении с точки зрения ресурсов:
Определите, какие ресурсы вы хотите открыть для внешнего мира
Используйте глаголы, уже определенные протоколом HTTP, для выполнения операций с этими ресурсами.

Вот как обычно реализуется служба REST:

Компоненты HTTP

HTTP определяет следующую структуру запроса:

Методы HTTP-запроса

Метод, используемый в HTTP-запросе, указывает, какое действие вы хотите выполнить с этим запросом. Важные примеры:

Код статуса ответа HTTP

Код состояния всегда присутствует в ответе HTTP. Типичные примеры:

Резюме

В статье приведен на верхнем уровне обзор архитектурного стиля REST. Подчеркивается тот факт, что HTTP является основным строительным блоком REST сервисов. HTTP — это протокол, который используется для определения структуры запросов и ответов браузера. Мы видели, что HTTP имеет дело главным образом с ресурсами, доступными на веб-серверах. Ресурсы идентифицируются с помощью URI, а операции над этими ресурсами выполняются с использованием глаголов, определенных протоколом HTTP.

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

Источник

Что такое REST API. REST, RESTful и RESTlike API, в чем разница?

Representational State Transfer — передача состояния представления.

REST означает передачу репрезентативного состояния. Это архитектурный шаблон для создания веб-сервисов. RESTful реализует этот шаблон.

Что такое REST?

Начнем с определения того, что такое REST, а что нет. Для некоторых REST означает сервер, который обменивается документами JSON с клиентом через HTTP. Это не совсем так. Спецификация REST не требует HTTP или JSON. (В спецификации вообще не упоминается JSON или XML.)

Немного истории REST

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

Филдинг не требует особых требований. Вместо этого он определяет REST относительно ограничений и архитектурных элементов.

Архитектурные ограничения REST

Применение ограничений

Во-первых, клиент-сервер, многоуровневая система и ограничения без состояния объединяются, чтобы сформировать приложение с твердыми границами и четким разделением задач. Данные передаются от сервера к клиенту по запросу. Клиент отображает или обрабатывает их. Если состояние изменяется, клиент отправляет его обратно на сервер для хранения. В REST клиент и сервер обмениваются знаниями о данных и состоянии. Архитектура не скрывает данные, она скрывает только реализации.

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

Это техническое определение REST. Как это выглядит в реальном мире?

RPC через HTTP против RESTful

Remote Procedure Call — вызов удалённых процедур. Их часто путают, смотря на URI или на то, как служба использует HTTP-команды. По тому, что складывается впечетлаение, что представление данных в REST это единый набор ресурсов.

Это различие иногда называют различием между вызовами удаленных процедур (RPC) и REST. Для примера разберем метод API для добавления и удаления товаров итернет магазина.

В одной версии есть один URL, который мы запрашиваем с помощью HTTP GET или POST. Мы взаимодействуем со службой, отправляя POST, задавая содержание, которое отражает то, что мы хотим сделать.

Дабавляем новый товар с помощью POST и NewItem:

Запрос данных о товаре с помощью POST и ItemRequest:

Также можно использовать GET.

Удаление или редактирование товаров с помощью POST и ItemDelete или ItemUpdate.

Это не REST. Мы не меняем состояние ресурсов. Мы вызываем функцию с аргументами, которые находятся в JSON или URL.

У службы RESTful есть URI для каждого товара.

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

Но на этом сходство заканчивается. Получение элемента всегда выполняется GET:

Важным моментом является то, что URI работают с данными, а не с удаленными методами.

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

REST против RESTful и модель зрелости Ричардсона

Когда вы моделируете свои URI после ресурсов и используете HTTP-команды, вы делаете свой API предсказуемым. Как только разработчики узнают, как вы определили свои ресурсы, они смогут почти предсказать, как будет выглядеть API. Здесь снова упор делается на понимание данных, а не операций.

Но даже если вы не можете сделать API полностью предсказуемым, вы можете задокументировать любую службу REST. Таким образом, каждый элемент, возвращаемый в рассмотреном выше приложении, будет содержать ссылки для удаления, изменения или установки уровня ресурса.

Многие API не соответствуют этому требованию, но называют себя REST. Дело в том, что многие так или иначе нарушают правила. В итоге мы получаем, что многие службы, которые мы называем REST, технически таковыми не являются.

REST, RESTful или RESTlike: имеет ли это значение?

Чем больше требований вы выполните, тем более «full» будет ваше приложение. При выполнении всех требований вы получайте RESTful приложение, если соблюдайте часть из них это RESTlike.

Итак, имеет ли значение сравнение REST и RESTful? Возможно нет. Насколько хорошо ваша архитектура соответствует произвольному стандарту, не так важно, чем то насколько она соответствует вашим потребностям и может ли она расти.

Архитектурный шаблон REST имеет много преимуществ. Филдинг разработал его еще в 2000 году, с тех пор многое изменилось. Но большинство ограничений, которые он имел в виду, все еще с нами. В 2000 году еще не было Android, iPhone или подобных систем. Но Филдинг понял, какие онлайн-приложения нужны и как веб-клиенты будут развиваться из механизмов отображения HTML в законченные приложения. Инструменты, которые мы используем сегодня, адаптированы к REST, а не наоборот.

Источник

Понимание основ работы API и REST API – краткое введение

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

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

REST – это стиль архитектуры API для распределенных систем. REST определяет, как данные представляются клиенту в удобном для него формате. Обмен данными происходит в формате JSON или XML (хотя сегодня более популярен формат JSON).

Понимание того, как данные обмениваются через Интернет

Обмен данными в Интернете происходит с помощью TCP/IP (протокол управления передачей/интернет-протокол). TCP/IP – это набор протоколов связи, который описывает, как взаимодействует огромное количество компьютеров, подключенных к Интернету.

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

TCP/IP использует стандартную модель связи клиент-сервер, когда клиент (компьютерное устройство) запрашивает ресурс у сервера (возможно, гораздо более крупного компьютерного устройства в удаленном месте). Соединения с использованием TCP/IP не сохраняют состояния – каждый запрос от клиента к серверу рассматривается как новый, сервер никогда не запоминает клиента. Это освобождает ресурсы на сервере, чтобы сделать его быстрее, и он быстрее отвечал на несколько запросов.

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

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

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

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

Кратко о различных шаблонах API

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

Стиль туннелирования

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

SOAP – Простой протокол доступа к объектам

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

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

REST

REST – это действительно API-интерфейс «веб-сервисов», помещающий его на противоположную сторону SOAP. REST API основаны на URI (унифицированный идентификатор ресурса) и протоколе HTTP. REST API могут обмениваться данными в формате JSON или XML, хотя многие API REST отправляют данные в виде JSON.

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

Что такое REST API

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

Каждый URL называется запросом, а отправленные вам данные называются ответом.

Анатомия запроса к API

Важно знать, что запрос состоит из четырех вещей:

REST API – определения дизайна. Рекомендации по проектированию

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

Метод GET и параметры его запроса не должны изменять состояние. Избегайте проектирования конечных точек вида:

Это очень плохо для вашего приложения. Если бот поисковой системы или какой-либо веб-сканер когда-либо завладеют этим URL…

Используйте подресурсы для отношений

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

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

Обрабатывайте ошибки с помощью HTTP-кодов состояния

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

Обеспечивайте нумерацию страниц, сортировку и фильтрацию

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

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

Основы безопасности API

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

Аутентификация

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

Авторизация

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

Краткое заключение

В этом уроке мы рассмотрели REST API-интерфейсы и несколько моментов, которые следует учитывать при их разработке. Мы кратко рассмотрели различные шаблоны API, немного подробнее мы остановились именно на REST API.

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

Источник