Что такое RESTful на самом деле / Хабр

А ваше приложение — RESTful? Чтобы ответить на этот вопрос нужно сначала разобраться что такое RESTful. Бытует мнение, что отдавать правильные коды ответов в HTTP — это уже RESTful. Или делать правильные идемпотентные HTTP-запросы — это вообще очень RESTful. Мы в Хекслете сделали практический курс по протоколу HTTP (отличия версий, отправка форм, аутентификация, куки и пр.), и в нем мы стараемся рассказать о правильном использовании запросов, но нужно понимать, что RESTful это не про HTTP, это вообще не про протоколы интернета. Современный веб и взаимодействие между браузером и сервером с помощью HTTP и URI могут удовлетворять принципам RESTful, а могут и не удовлетворять.

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

Если вы занимаетесь веб-разработкой, вы скорее всего слышали о REST. Но если вы такой же как я, то обычно вы притворяетесь и вежливо киваете когда у вас спрашивают, делаете ли вы все RESTful. Я использую HTTP, эээ, значит — это RESTful, так? Недавно я решил наконец выяснить, что означает это модное словечко, которое звучит так умиротворяюще («restful» с англ. «успокоительный», «спокойный»).

Что такое REST?

REST — это аббревиатура от Representational State Transfer («передача состояния представления»). Это согласованный набор архитектурных принципов для создания более масштабируемой и гибкой сети. Эти принципы отвечают на ряд вопросов. Какие у системы компоненты? Как они должны взаимодействовать друг с другом? Как быть уверенным, что можно заменять различные части системы в любое время? Как система может масштабироваться для обслуживания миллиардов пользователей?

Рой Филдинг первым использовал термин REST в 2000 году в своей докторской диссертации «Архитектурные стили и дизайн программных сетевых архитектур». На момент публикации диссертации Всемирная паутина (Web) была уже очень популярна. Филдинг, по существу, шагнул назад и проанализировал черты, которые сделали Web более успешным, чем конкурирующие протоколы Интернета. Затем он выработал концепцию фреймворка для создания сетевой коммуникации, подобной браузеру. Так что REST — это общий набор принципов, характерных не только для Web. Он может быть применен к другим видам сетей, таким как встроенные системы. REST — не протокол, так как он не задаёт деталей реализации.

Ограничения Филдинга

В диссертации Филдинга есть группа архитектурных ограничений, которым должна удовлетворять система, соответствующая требованиям RESTful. Ниже я даю краткий обзор каждого из этих ограничений и рассуждаю как Web удовлетворяет им, на основании его основных технологий: HTTP, HTML, и URI. (Если вы не знакомы с URI, считайте его «URL». Они отличаются, но в нашем обсуждении это не важно). Давайте разберём каждое из ограничений Филдинга.

Клиент-сервер

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

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

Отсутствие состояния

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

Единообразие интерфейса

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

1-е ограничение интерфейса: определение ресурсов

Первое субограничение «унифицированного интерфейса» влияет на то, как идентифицируются ресурсы. В терминологии REST что угодно может быть ресурсом — HTML-документ, изображение, информация о конкретном пользователе и т.д. Каждый ресурс должен быть уникально обозначен постоянным идентификатором. «Постоянный» означает, что идентификатор не изменится за время обмена данными, и даже когда изменится состояние ресурса. Если ресурсу присваивается другой идентификатор, сервер должен сообщить клиенту, что запрос был неудачным и дать ссылку на новый адрес.

Web использует URI для идентификации ресурсов, а HTTP — в качестве стандарта коммуникации. Чтобы получить ресурс, хранящийся на сервере, клиент делает к URI HTTP-GET-запрос, который идентифицирует этот ресурс. Каждый раз, когда вы набираете в браузере какой-то адрес, браузер делает GET-запрос на этот URI. Если браузер принимает в ответ 200 OK и HTML-документ обратно, то браузер рендерит страницу в окне, и вы ее видите.

2-е ограничение интерфейса: управление ресурсами через представления

Второе субограничение «унифицированного интерфейса» говорит, что клиент управляет ресурсами, направляя серверу представления, обычно в виде JSON-объекта, содержащего контент, который он хотел бы добавить, удалить или изменить. В REST у сервера полный контроль над ресурсами, и он отвечает за любые изменения. Когда клиент хочет внести изменения в ресурсы, он посылает серверу представление того, каким он видит итоговый ресурс. Сервер принимает запрос как предложение, но за ним всё так же остаётся полный контроль.

Давайте рассмотрим блог в качестве примера. Когда пользователь создаёт новый пост в блоге, его компьютер должен сообщить серверу, что в блог нужно добавить новую запись. Чтобы это выполнить, он посылает HTTP-POST-запрос или PUT-запрос с содержимым в виде новой записи в блоге. Сервер возвращает ответ, указывающий, что запись создана или была проблема. В не-REST мире клиент может в буквальном смысле давать инструкции операциям, вроде «добавить новую строку» и «присвоить записи название», вместо обычной отправки представления того, каким он видит конечный ресурс.

3-е ограничение интерфейса: самодостаточные сообщения

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

Чтобы понять, как это касается WEB, давайте проанализируем набор HTTP запросов и ответов.

Когда пользователь набирает www.example.com в адресной строке веб-браузера, браузер отправляет соответствующий HTTP-запрос:

GET / HTTP/1.1

Host: www.example.com


Это самодостаточное сообщение, потому что оно передаёт серверу какой был использован HTTP-метод и какой протокол (HTTP 1.1).

Сервер может послать ответ вроде такого:

HTTP / 1.1 200 OK

Content-Type: text/html

<!DOCTYPE html>

Home Page

Hello World!

Check out the Recurse Center!

Это самодостаточное сообщение, потому что оно сообщает клиенту, как интерпретировать текст сообщения (благодаря Content-type = text/html). У клиента есть всё, что необходимо, в этом одном сообщении для обработки его соответствующим образом.

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

4-е ограничение интерфейса: гипермедиа

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

HTML — это один из видов гипермедиа. Чтобы лучше это понять, давайте еще раз посмотрим на ответ сервера выше.

<a href= “http://www.recurse.com”> Check out the Recurse Center!</a>

сообщает клиенту, что он должен сделать GET-запрос к www.recurse.com, если пользователь нажимает на ссылку.

<img src="awesome-pic.jpg">

говорит клиенту немедленно сделать GET-запрос к www. example.com/awesome-pic.jpg, чтобы тот отобразил изображение для пользователя.

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

Другие ограничения Филдинга: кэширование, система слоёв и код по требованию

Есть еще три ограничения Филдинга, которые мы здесь рассмотрим кратко.

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

Система слоёв предполагает наличие большего количества компонентов, чем клиент и сервер. В системе может быть больше одного слоя. Тем не менее, каждый компонент ограничен способностью видеть только соседний слой и взаимодействовать только с ним. Прокси — это дополнительный компонент, он ретранслирует HTTP-запросы на серверы или другие прокси. Прокси-серверы могут быть полезны для балансировки нагрузки и проверок безопасности. Прокси действует как сервер для начального клиента, который посылает запрос, а затем как клиент, когда ретранслирует эту просьбу. Шлюз — это еще один дополнительный компонент, он переводит HTTP-запрос в другой протокол, распространяет этот запрос, а затем переводит полученный ответ обратно в HTTP. Клиент может обращаться со шлюзом, как с обычным сервером. Пример шлюза — система, которая загружает файлы с FTP-сервера.

Код по требованию — единственное опциональное ограничение, которое предполагает отправку сервером исполняемого кода клиенту. Это то, что происходит в HTML-теге

<script>

. Когда HTML-документ загружается, браузер автоматически выбирает на сервере JavaScript и исполняет его локально.

* * *

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

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

К прочтению

• The RESTful Cookbook
• Книга: RESTful Web APIs
• Личный блог Роя Т. Филдинга

Перевод: Наталия Басс

Что такое RESTful API? – Руководство для начинающих по RESTful API – AWS

Что такое RESTful API?

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

Что такое API?

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

Таким образом, сетевой API функционирует как шлюз между клиентами и ресурсами в Интернете.

Клиенты

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

Ресурсы

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

Что такое REST?

Representational State Transfer (REST) — это программная архитектура, которая определяет условия работы API. Первоначально REST создавалась как руководство для управления взаимодействиями в сложной сети, такой как Интернет. Архитектуру на основе REST можно использовать для поддержки высокопроизводительной и надежной связи в требуемом масштабе. Ее можно легко внедрять и модифицировать, обеспечивая прозрачность и кросс-платформенную переносимость любой системы API.

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

Ниже приведены некоторые принципы архитектурного стиля REST:

Единый интерфейс

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

Единый интерфейс накладывает четыре архитектурных ограничения:

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

Отсутствие сохранения состояния

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

Многоуровневая система

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

Емкость кэша

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

Код по запросу

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

В чем заключаются преимущества RESTful API?

RESTful API обладает следующими преимуществами:

Возможность масштабирования

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

Гибкость

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

Независимость

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

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

Базовый принцип работы RESTful API совпадает с принципом работы в Интернете. Клиент связывается с сервером с помощью API, когда ему требуется какой-либо ресурс. Разработчики описывают принцип использования REST API клиентом в документации на API серверного приложения. Ниже представлены основные этапы запроса REST API:

1. Клиент отправляет запрос на сервер. Руководствуясь документацией API, клиент форматирует запрос таким образом, чтобы его понимал сервер.
2. Сервер аутентифицирует клиента и подтверждает, что клиент имеет право сделать этот запрос.
3. Сервер получает запрос и внутренне обрабатывает его.
4. Сервер возвращает ответ клиенту. Ответ содержит информацию, которая сообщает клиенту, был ли запрос успешным. Также запрос включает сведения, запрошенные клиентом.

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

Что содержит клиентский запрос RESTful API?

API RESTful требует, чтобы запросы содержали следующие основные компоненты:

Уникальный идентификатор ресурса

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

Метод

Как правило, разработчики реализуют RESTful API с помощью протокола передачи гипертекста (HTTP). Метод HTTP сообщает серверу, что ему необходимо сделать с ресурсом. Ниже приведены четыре распространенных метода HTTP:

GET

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

POST

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

PUT

Клиенты используют PUT для обновления существующих на сервере ресурсов. В отличие от POST, отправка одного и того же запроса PUT несколько раз дает один и тот же результат в веб-службе RESTful.

DELETE

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

Заголовки HTTP

Заголовки запросов — это метаданные, которыми обмениваются клиент и сервер. Например, заголовок запроса указывает формат запроса и ответа, предоставляет информацию о статусе запроса и т. д.

Данные

Запросы REST API могут включать данные для успешной работы POST, PUT и других методов HTTP.

Параметры

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

• Параметры пути, которые определяют детали URL.
• Параметры запроса, которые запрашивают дополнительную информацию о ресурсе.
• Параметры cookie, которые быстро аутентифицируют клиентов.

Что такое методы аутентификации RESTful API?

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

RESTful API поддерживает четыре распространенных метода аутентификации:

HTTP-аутентификация

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

Базовая аутентификация

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

Аутентификация носителя

Аутентификация носителя — это процесс предоставления управления доступом носителю токена. Как правило, токен носителя представляет собой зашифрованную строку символов, которую сервер генерирует в ответ на запрос входа в систему. Клиент отправляет токен в заголовках запроса для доступа к ресурсам.

Ключи API

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

OAuth

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

Что содержит ответ сервера RESTful API?

Принципы REST требуют, чтобы ответ сервера содержал следующие компоненты:

Строка состояния

Строка состояния содержит трехзначный код состояния, который сообщает об успешном или неудачном выполнении запроса. Например, коды 2XX указывают на успешное выполнение, а коды 4XX и 5XX — на ошибки. Коды 3XX указывают на перенаправление URL.

Ниже приведены некоторые распространенные коды состояния:

• 200: общий ответ об успешном выполнении
• 201: ответ об успешном выполнении метода POST
• 400: неверный запрос, который сервер не может обработать
• 404: ресурс не найден

Текст сообщения

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

‘{«name»:»John», «age»:30}’

Заголовки

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

Как AWS может помочь в управлении RESTful API?

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

С помощью API Gateway можно:

• Предоставить пользователям высокую производительность при запросах и ответах API.
• Разрешить доступ к API с помощью AWS Identity and Access Management (IAM) и Amazon Cognito, которые обеспечивают встроенную поддержку OAuth.
• Запускать несколько версий одного и того же API одновременно с помощью API Gateway, что позволяет быстро дорабатывать, тестировать и запускать новые версии.
• Отслеживать метрики производительности и информацию о запросах API, задержке данных и частоте ошибок из API Gateway. 

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

Что остальное — Учебник по API REST

Последнее обновление: 7 апреля, 2022

: Lokesh Gupta

Rest — аббревиатура для Re презентация S Tate T Ransfer и архитектурный стиль для S Tate T Ransfer и архитектурный стиль для S Tate T и архитектурный стиль для . распределенные системы гипермедиа . Рой Филдинг впервые представил его в 2000 году в своей знаменитой диссертации.

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

Веб-API (или веб-служба), соответствующий архитектурному стилю REST,  REST API .

1. Руководящие принципы REST

Шесть руководящих принципов или ограничений архитектуры RESTful:

1.1. Единый интерфейс

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

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

Следующие четыре ограничения могут обеспечить единый интерфейс REST:

• Идентификация ресурсов  — Интерфейс должен однозначно идентифицировать каждый ресурс, участвующий во взаимодействии между клиентом и сервером.
• Управление ресурсами через представления  – Ресурсы должны иметь единообразные представления в ответе сервера. Потребители API должны использовать эти представления для изменения состояния ресурсов на сервере.
• Самоописательные сообщения  – Каждое представление ресурса должно содержать достаточно информации, чтобы описать, как обрабатывать сообщение. Он также должен предоставлять информацию о дополнительных действиях, которые клиент может выполнять с ресурсом.
• Гипермедиа как механизм состояния приложения  – клиент должен иметь только начальный URI приложения. Клиентское приложение должно динамически управлять всеми другими ресурсами и взаимодействиями с использованием гиперссылок.

1.2. Клиент-сервер

Шаблон проектирования клиент-сервер обеспечивает разделение задач , что помогает клиентскому и серверному компонентам развиваться независимо друг от друга.

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

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

1.3. Без гражданства

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

Сервер не может использовать какую-либо ранее сохраненную контекстную информацию на сервере.

По этой причине клиентское приложение должно полностью сохранять состояние сеанса.

1.4. Cacheable

Ограничение Cacheable требует, чтобы ответ явно или неявно помечал себя как кэшируемый или некэшируемый.

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

1.5. Многоуровневая система

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

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

1.6. Код по запросу (

Дополнительно )

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

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

2. Что такое ресурс?

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

Состояние ресурса в любой конкретный момент времени известно как представление ресурса .

Представления ресурсов состоят из:

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

REST API состоит из набора взаимосвязанных ресурсов. Этот набор ресурсов известен как REST API’s  9.0024 ресурсная модель .

2.1. Идентификаторы ресурсов

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

2.2. Hypermedia

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

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

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

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

— Рой Филдинг

2.3. Самоописательный

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

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

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

Типы носителей не имеют никакого отношения к методам ресурсов GET/PUT/POST/DELETE/…, за исключением того факта, что некоторые элементы типов носителей будут определять модель процесса, которая выглядит как «элементы привязки с атрибутом href создают гипертекст ссылка, которая при выборе вызывает поисковый запрос (GET) для URI, соответствующего атрибуту CDATA -encoded href ».

3. Методы ресурсов

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

Многие люди ошибочно связывают методы ресурсов с методами HTTP (например, GET/PUT/POST/DELETE). Рой Филдинг никогда не упоминал никаких рекомендаций относительно того, какой метод следует использовать в каких условиях. Все, что он подчеркивает, это то, что это должен быть единый интерфейс .

Например, если мы решим, что API-интерфейсы приложений будут использовать HTTP POST для обновления ресурса — вместо того, чтобы большинство людей рекомендовало HTTP PUT — все в порядке. Тем не менее, интерфейс приложения будет RESTful.

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

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

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

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

4. REST и HTTP — это не одно и то же

Многие люди предпочитают сравнивать HTTP с REST. REST и HTTP — это не одно и то же.

REST != HTTP

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

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

5. Резюме

Проще говоря, в архитектурном стиле REST данные и функции считаются ресурсами, доступ к которым осуществляется с помощью унифицированных идентификаторов ресурсов (URI).

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

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

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

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

Все эти принципы помогают приложениям RESTful быть простыми, легкими и быстрыми.

Ссылки:

• REST API должны управляться гипертекстом
• REST Arch Style

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

Последнее обновление: 9022

от: Lokesh Gupta

REST STADS для RE ПРЕЗПЕТАНИЕ S TATE T RANSFER, термин «Королев поля» в 2000 году. Это стиль архитектуры для разработки слабосвязанных приложений по сети, который часто используется при разработке веб-сервисов.

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

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

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

REST определяет 6 архитектурных ограничений , которые делают любой веб-сервис действительно RESTful API.

1. Единый интерфейс
2. Клиент-сервер
3. Без сохранения состояния
4. Кэшируемый
5. Многоуровневая система
6. Код по запросу (необязательно)

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

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

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

Кроме того, представления ресурсов в системе должны соответствовать определенным рекомендациям, таким как соглашения об именах, форматы ссылок или формат данных (XML и/или JSON).

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

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

2. Клиент-сервер

Это ограничение по сути означает, что клиентские и серверные приложения ДОЛЖНЫ иметь возможность развиваться отдельно, без какой-либо зависимости друг от друга. Клиент должен знать только URI ресурсов, и все. Сегодня это стандартная практика в веб-разработке, поэтому с вашей стороны не требуется ничего особенного. Будь проще.

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

3. Без гражданства

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

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

Контекст клиента не должен храниться на сервере между запросами. Клиент отвечает за управление состоянием приложения.

4. Кэширование

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

В REST кэширование должно применяться к ресурсам, когда это применимо, и затем эти ресурсы ДОЛЖНЫ объявить себя кэшируемыми. Кэширование может быть реализовано на сервере или на стороне клиента.

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

5. Многоуровневая система

REST позволяет вам использовать многоуровневую системную архитектуру, в которой вы развертываете API на сервере A, храните данные на сервере B и аутентифицируете запросы, например, на сервере C.

This entry was posted in Популярное