Posted:
Ноя 23, 2022
Comments:
0 Comments

Rest разработка: Введение в REST API — RESTful веб-сервисы / Хабр

Содержание

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

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

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

  • Различия REST и SOAP

  • Разработка REST API — что такое Contract First (контракт в первую очередь)?

  • Разработка REST API — что такое Code First (код в первую очередь)?

  • REST API — Что такое HATEOAS?

  • Рекомендации по REST API — примеры проектирования веб-сервисов на Java и Spring


Она содержит введение в RESTful веб-сервисы и краткий обзор REST и HTTP.

Intro to RESTful Web Services


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

Вы изучите:

  • Что такое REST?

  • На чем основан REST API?

  • Как используется HTTP при создании REST API?

  • Что такое ресурс?

  • Как вы определяете ресурсы REST API?

  • Каковы лучшие практики при разработке REST 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 — универсальный идентификатор ресурса. Например:

  • Создать пользователя: POST /users

  • Удалить пользователя: DELETE /users/1

  • Получить всех пользователей: GET /users

  • Получить одного пользователя: GET /users/1

REST и Ресурсы


Важно отметить, что с REST вам нужно думать о приложении с точки зрения ресурсов:

Определите, какие ресурсы вы хотите открыть для внешнего мира

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

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

  • Формат обмена данными: здесь нет никаких ограничений. JSON — очень популярный формат, хотя можно использовать и другие, такие как XML

  • Транспорт: всегда HTTP. REST полностью построен на основе HTTP.

  • Определение сервиса: не существует стандарта для этого, а REST является гибким. Это может быть недостатком в некоторых сценариях, поскольку потребляющему приложению может быть необходимо понимать форматы запросов и ответов. Однако широко используются такие языки определения веб-приложений, как WADL (Web Application Definition Language) и Swagger.


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

Компоненты HTTP


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

  • строка запроса (request line) — определяет тип сообщения

  • заголовки запроса (header fields) — характеризуют тело сообщения, параметры передачи и прочие сведения

  • тело сообщения (body) — необязательное


HTTP определяет следующую структуру ответного сообщения (response):

  • строка состояния (status line), включающая код состояния и сообщение о причине

  • поля заголовка ответа (header fields)

  • дополнительное тело сообщения (body)

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


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

  • GET: получить подробную информацию о ресурсе

  • POST: создать новый ресурс

  • PUT: обновить существующий ресурс

  • DELETE: Удалить ресурс

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


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

  • 200 — успех

  • 404 — cтраница не найдена


По этому вопросу имеется авторское видео.

Резюме


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

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

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

Foundations of RESTful Architecture
Developing REST APIs

Разработка REST API — что такое Code First подход? / Хабр

Это четвертая статья в серии статей по REST API:

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

  • Различия REST и SOAP

  • Разработка REST API — что такое Contract First (контракт в первую очередь)?

  • Разработка REST API — что такое Code First (код в первую очередь)?

  • REST API — Что такое HATEOAS?

  • Рекомендации по REST API — примеры проектирования веб-сервисов на Java и Spring


В этой статье мы продолжим знакомство с разработкой REST API и рассмотрим подход Code-First.

Разработка хорошего REST API важна для того, чтобы иметь хорошие микросервисы. Подход Code-First фокусируется на генерации контракта из кода. Это наилучший из возможных подходов?

Вы изучите

  • Что такое Code-First подход к разработке REST API?

  • Каковы преимущества подхода Code-First?

  • Каковы недостатки подхода Code-First?

  • Когда вы использовать подход Code-First?

Что такое Code-First подход?


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

  • Code First и генерируйте контракт из кода

  • Contract First и разработка кода на основе контракта


Давайте начнем с быстрого примера для Code First.

Spring Boot Code First пример REST API


Мы разрабатываем RESTful веб-сервис, используя Spring Boot Framework для генерации API. Например, в API retrieveAllUsers () мы открываем URI «/users» и

возвращаем всех пользователей (ресурс /users),

вызывая метод сервиса.

Когда мы переходим на этот URL, мы возвращаем всех пользователей:

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

Swagger позволяет нам генерировать документацию из кода. Например, вот что Swagger генерирует для запроса на получение всех пользователей:

Он выводит тип получаемого нами ответного сообщения и сопровождающий его статус ответа. Вы даже можете вызвать этот сервис из Swagger получить ответ:

Вы также можете отправить запрос POST в «/users«:

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

Преимущества Code First


Основные преимущества этого подхода:

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

  • Синхронизация кода и контракта: поскольку контракт генерируется из кода, они всегда синхронизируются друг с другом

Недостатки Code First


Недостатки этого подхода заключаются в следующем:

Нет параллельной разработки


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

Нет цели для команд


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

Нет кроссплатформенной совместимости


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

По этому вопросу имеется авторское видео.

Резюме


В этой статье мы исследовали Code First подход построения REST API. Несмотря на то, что подход, основанный на коде, эффективен с точки зрения разработчика, он сталкивается с серьезными проблемами, когда речь идет о совместной разработке поставщика и потребителя.

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

API Development: Design-First or Code-First?
How to Develop a RESTful Web Service in ASP.NET Web API

Что такое ОТДЫХ? | Codecademy

Репрезентативная передача состояния

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

Разделение клиента и сервера

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

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

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

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

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

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

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

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

Связь между клиентом и сервером

В архитектуре REST клиенты отправляют запросы на получение или изменение ресурсов, а серверы отправляют ответы на эти запросы. Давайте рассмотрим стандартные способы отправки запросов и ответов.

Выполнение запросов

REST требует, чтобы клиент делал запрос на сервер, чтобы получить или изменить данные на сервере. Запрос обычно состоит из:

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

Существует 4 основных HTTP-глагола, которые мы используем в запросах для взаимодействия с ресурсами в системе REST:

  • GET — получить определенный ресурс (по идентификатору) или набор ресурсов
  • POST — создать новый ресурс
  • PUT — обновить конкретный ресурс (по id)
  • DELETE — удалить определенный ресурс по id

Вы можете узнать больше об этих HTTP-глаголах в следующей статье Codecademy:

  • Что такое CRUD?

В заголовке запроса клиент отправляет тип контента, который он может получить от сервера. Это называется полем Accept , и оно гарантирует, что сервер не отправит данные, которые не могут быть поняты или обработаны клиентом. Варианты типов содержимого — это типы MIME (или многоцелевые расширения почты Интернета, о которых вы можете узнать больше в веб-документах MDN).0003

Типы MIME, используемые для указания типов содержимого в поле Accept , состоят из типа и подтипа . Они разделены косой чертой (/).

Например, текстовый файл, содержащий HTML, будет указан с типом text/html . Если бы этот текстовый файл содержал вместо этого CSS, он был бы указан как text/css . Общий текстовый файл будет обозначаться как text/plain . Однако это значение по умолчанию, text/plain , не является универсальным. Если клиент ожидает text/css и получает text/plain , он не сможет распознать содержимое.

Другие типы и часто используемые подтипы:

  • изображение — изображение/png , изображение/jpeg , изображение/gif
  • аудио — аудио/wav , аудио/mpeg
  • видео — видео/mp4 , видео/ogg
  • приложение — приложение/json , приложение/pdf , приложение/xml , приложение/октет-поток

Например, клиент, получающий доступ к ресурсу с id 23 в ресурсе article на сервере, может отправить запрос GET следующим образом:

 GET /articles/23
Accept: text/html, application/xhtml

Поле заголовка Accept в этом случае говорит о том, что клиент примет содержимое в text/html или application/xhtml .

Пути

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

Обычно первая часть пути должна быть множественной формой ресурса. Это делает вложенные пути простыми для чтения и понимания.

Путь, подобный fashionboutique.com/customers/223/orders/12 , ясен в том, на что он указывает, даже если вы никогда раньше не видели этот конкретный путь, потому что он иерархичен и описателен. Мы видим, что мы обращаемся к порядку с id 12 для клиента с id 223.

Пути должны содержать информацию, необходимую для поиска ресурса с требуемой степенью специфичности. При обращении к списку или набору ресурсов не всегда необходимо добавлять id . Например, POST-запрос к пути fashionboutique.com/customers не требует дополнительного идентификатора, так как сервер сгенерирует идентификатор для нового объекта.

Если мы пытаемся получить доступ к одному ресурсу, нам нужно добавить id на путь.
Например:
GET fashionboutique.com/customers/:id — извлекает товар из ресурса customers с указанным id .
DELETE fashionboutique.com/customers/:id — удаляет товар в ресурсе customers с указанным id .

Отправка ответов

Типы содержимого

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

Например, когда клиент обращается к ресурсу с id 23 в ресурсе статей с этим запросом GET:

 GET /articles/23 HTTP/1. 1
Принять: text/html, application/xhtml

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

 HTTP/1.1 200 (ОК)
Content-Type: text/html

Это будет означать, что запрошенный контент возвращается в теле ответа с типом контента из text/html , который, по словам клиента, он сможет принять.

Коды ответов

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

Код состояния Значение
200 (ОК) Это стандартный ответ для успешных HTTP-запросов.
201 (СОЗДАН) Это стандартный ответ на HTTP-запрос, который привел к успешному созданию элемента.
204 (БЕЗ СОДЕРЖИМОГО) Это стандартный ответ для успешных HTTP-запросов, когда в теле ответа ничего не возвращается.
400 (НЕПРАВИЛЬНЫЙ ЗАПРОС) Запрос не может быть обработан из-за неправильного синтаксиса запроса, чрезмерного размера или другой ошибки клиента.
403 (ЗАПРЕЩЕНО) У клиента нет разрешения на доступ к этому ресурсу.
404 (НЕ НАЙДЕН) В настоящее время не удалось найти ресурс. Возможно, он был удален или еще не существует.
500 (ВНУТРЕННЯЯ ОШИБКА СЕРВЕРА) Общий ответ на непредвиденный сбой, если нет более конкретной информации.

Для каждой команды HTTP существуют ожидаемые коды состояния, которые сервер должен вернуть в случае успеха:

  • ПОЛУЧИТЬ — вернуть 200 (ОК)
  • ПОЧТА — возврат 201 (СОЗДАН)
  • PUT — возврат 200 (ОК)
  • УДАЛИТЬ — вернуть 204 (БЕЗ СОДЕРЖИМОГО)
    Если операция завершится ошибкой, верните максимально конкретный код состояния, соответствующий возникшей проблеме.
Примеры запросов и ответов

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

Если бы мы хотели просмотреть всех клиентов, запрос выглядел бы так:

 GET http://fashionboutique.com/customers
Accept: application/json

Возможный заголовок ответа будет выглядеть так:

 Код состояния: 200 (ОК)
Тип содержимого: application/json

, за которым следуют данные клиентов , запрошенные в формате application/json .

Создайте нового клиента, разместив данные:

 POST http://fashionboutique.com/customers
Тело:
{
  "покупатель": {
    «имя» = «Scylla Buss»,
    «электронная почта» = «[электронная почта защищена]»
  }
}

Затем сервер генерирует идентификатор для этого объекта и возвращает его клиенту с заголовком вроде:

 201 (СОЗДАНО)
Content-type: application/json

Чтобы просмотреть одного клиента, мы GET его, указав идентификатор этого клиента:

 GET http://fashionboutique. com/customers/123
Принять: приложение/json

Возможный заголовок ответа будет выглядеть так:

 Код состояния: 200 (ОК)
Content-type: application/json

, за которым следуют данные для ресурса клиента с идентификатором 23 в формате application/json .

Мы можем обновить этого клиента с помощью PUT , указав новые данные:

 PUT http://fashionboutique.com/customers/123
Тело:
{
  "покупатель": {
    «имя» = «Scylla Buss»,
    «электронная почта» = «[электронная почта защищена]»
  }
}

Возможный заголовок ответа будет иметь Код состояния: 200 (ОК) , чтобы уведомить клиента о том, что элемент с id 123 был изменен.

Мы также можем УДАЛИТЬ этого клиента, указав его id :

 УДАЛИТЬ http://fashionboutique.com/customers/123

Ответ будет иметь заголовок, содержащий Код состояния: 204 (NO CONTENT4) , уведомляя клиента о том, что элемент с id 123 удален, а в теле ничего нет.

Практика с REST

Давайте представим, что мы создаем сайт для сбора фотографий. Мы хотим создать API для отслеживания пользователей, мест проведения и фотографий этих мест. Этот сайт имеет index.html и style.css . У каждого пользователя есть имя пользователя и пароль. У каждой фотографии есть место и владелец (то есть пользователь, который сделал снимок). Каждое заведение имеет название и почтовый адрес.
Можете ли вы спроектировать систему REST, которая бы вмещала:

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

Начните с написания:

  • какие запросы мы хотели бы сделать
  • какие ответы должен возвращать сервер
  • каким должен быть тип содержимого каждого ответа

Возможное решение — модели 

 {
  "пользователь": {
    "id": <Целое>,
    «имя пользователя»: ,
    «пароль»: 
  }
} 
 {
  "Фото": {
    "id": <Целое>,
    «venue_id»: <целое число>,
    «author_id»: <Целое число>
  }
} 
 {
  "место проведения": {
    "id": <Целое>,
    «имя»: <строка>,
    «адрес»: 
  }
}

Возможное решение — запросы/ответы

запросы GET

запросы-
ПОЛУЧИТЬ /index. html
Принять: текст/html
Ответ-
200 (ОК)
Тип контента: text/html

Запрос-
ПОЛУЧИТЬ /style.css
Принять: текст/CSS
Ответ-
200 (ОК)
Тип контента: text/css

Запрос-
ПОЛУЧИТЬ /места
Принять: приложение/json
Ответ-
200 (ОК)
Тип контента: приложение/json

Запрос-
ПОЛУЧИТЬ /места/:id
Принять: приложение/json
Ответ-
200 (ОК)
Тип контента: приложение/json

Запрос-
ПОЛУЧИТЬ /места/:id/фотографии/:id
Принять: приложение/json
Ответ-
200 (ОК)
Тип контента: image/png

Запросы POST

Запрос-
ПОЧТ/пользователи
Ответ-
201 (СОЗДАН)
Тип контента: приложение/json

Запрос-
ПОЧТА /объекты
Ответ-
201 (СОЗДАН)
Тип контента: приложение/json

Запрос-
ПОЧТА /места/:id/фотографии
Ответ-
201 (СОЗДАН)
Тип контента: application/json

PUT Requests

Request-
ПОСТАВИТЬ /пользователи/: идентификатор
Ответ-
200 (ОК)

Запрос-
PUT /места/:id
Ответ-
200 (ОК)

Запрос-
PUT /места/:id/фотографии/:id
Ответ-
200 (ОК)

УДАЛИТЬ Запросы

Запрос-
УДАЛИТЬ /места/:id
Ответ-
204 (БЕЗ СОДЕРЖИМОГО)

Запрос-
УДАЛИТЬ /места/:id/фотографии/:id
Ответ-
204 (No Content)

Узнайте больше на Codecademy

Pro Tomply

PATH

Создайте заднее приложение с JavaScript

Floodner,

. Средний,

4 Уроки

Что такое REST API?

Введите ключевые слова

Свяжитесь с нами

Select a language

  • 简体中文
  • English
  • Français
  • Deutsch
  • Italiano
  • 日本語
  • 한국어
  • Português
  • Español

Добро пожаловать,

Войдите в свою учетную запись Red Hat

Войдите в систему

Ваша учетная запись Red Hat дает вам доступ к вашему профилю участника и предпочтениям, а также к следующим услугам в зависимости от вашего статуса клиента:

Зарегистрируйтесь сейчас

Еще не зарегистрированы? Вот несколько причин, по которым это необходимо:

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

Редактировать свой профиль и предпочтения

Ваша учетная запись Red Hat дает вам доступ к вашему профилю участника, предпочтениям и другим услугам в зависимости от вашего статуса клиента.

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

Выход

Логин аккаунта

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

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

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

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

Еще одно преимущество API заключается в том, что вам не нужно знать особенности кэширования — как извлекается ваш ресурс или откуда он берется.

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

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

Когда клиентский запрос выполняется через RESTful API, он передает представление состояния ресурса запрашивающей стороне или конечной точке. Эта информация или представление доставляется в одном из нескольких форматов через HTTP: JSON (обозначение объектов Javascript), HTML, XLT, Python, PHP или обычный текст. JSON является наиболее популярным форматом файлов для использования, потому что, несмотря на свое название, он не зависит от языка, а также удобен для чтения как людьми, так и машинами.

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

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

  • Архитектура клиент-сервер, состоящая из клиентов, серверов и ресурсов, с запросами, управляемыми через HTTP.
  • Взаимодействие клиент-сервер без сохранения состояния, означающее, что информация о клиенте не сохраняется между запросами на получение, и каждый запрос является отдельным и не связанным.
  • Кэшируемые данные, упрощающие взаимодействие клиент-сервер.
  • Единый интерфейс между компонентами для передачи информации в стандартной форме. Это требует, чтобы:
    • Запрошенные ресурсы идентифицируемы и отделены от представлений, отправляемых клиенту.
    • ресурсы могут управляться клиентом через представление, которое они получают, поскольку представление содержит достаточно информации для этого.
    • самоописательные сообщения, возвращаемые клиенту, содержат достаточно информации, чтобы описать, как клиент должен их обрабатывать.
    • доступен гипертекст/гипермедиа. Это означает, что после доступа к ресурсу клиент должен иметь возможность использовать гиперссылки, чтобы найти все другие доступные в настоящее время действия, которые он может предпринять.
  • Многоуровневая система, организующая каждый тип серверов (отвечающих за безопасность, балансировку нагрузки и т. д.), включала извлечение запрошенной информации в виде иерархий, невидимых для клиента.
  • Код по запросу (необязательно): возможность отправлять исполняемый код с сервера клиенту по запросу, расширяя функциональные возможности клиента.

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

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