Архитектура: REST и RESTful

задняя часть Архитектура RESTful

Введение

В последние годы микросервисы развиваются полным ходом, и вызовы между микросервисами постепенно переходят от вызовов RPC к вызовам HTTP. Поэтому я часто слышу, как некоторые коллеги говорят, что мы предоставляем микросервисы и предоставляем интерфейсы RESTful другим системам, но что такое интерфейсы RESTful? Какое это имеет отношение к REST? Не волнуйтесь, эта статья поможет вам узнать.

REST

REST — это архитектура.

Первое, что нам нужно помнить, это то, что REST — это архитектурный подход, а не протокол. Он просто говорит нам, как построить надежную систему.

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

Архитектура REST очень распространена в современных веб-приложениях. Она не требует специального кодирования. Это всего лишь схема руководства высокого уровня. Конкретная реализация все еще зависит от вас.

REST и RESTful API

Мы только что рассмотрели REST, так какое же отношение REST имеет к RESTful API?

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

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

Основы архитектуры REST

Так какую же систему можно назвать системой архитектуры REST? Согласно статье Роя Филдинга, системы с архитектурой REST имеют 6 основных характеристик. Давайте объясним их один за другим.

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

В архитектуре REST наиболее важным элементом является ресурс. Мы определяем ресурсы как отдельные URI. Ресурс представлен отдельным и уникальным URI.

Отдельный ресурс не может быть слишком большим или слишком маленьким, он представляет собой независимую операционную единицу. Эти ресурсы приобретаются и управляются с помощью обычных методов приобретения. Например, CURD ресурсов может быть представлен различными HTTP-методами (PUT, POST, GET, DELETE).

При этом необходимо единообразно именовать ресурсы и определять единый формат ссылок и формат данных.

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

Spring также обеспечивает поддержку HATEOAS, давайте посмотрим на базовый запрос HATEOAS:

GET http://localhost:8080/greeting

Возврат этого запроса может быть таким:

{
  "content":"Hello, World!",
  "_links":{
    "self":{
      "href":"http://localhost:8080/greeting?name=World"
    }
  }
}

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

Клиент-сервер Клиент и сервер независимы

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

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

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

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

без гражданства

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

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

Кэшируемый

Кэширование — это мощный инструмент для повышения скорости системы. То же самое относится и к ресурсам REST. В REST кэшируемые ресурсы должны быть помечены как кэшируемые.

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

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

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

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

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

Примеры RESTful API

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

Запрос объекта:

GET https://services.odata.org/TripPinRESTierService/People

Запрос объекта по ID:

GET https://services.odata.org/TripPinRESTierService/People('russellwhyte')

Запросить атрибут объекта:

GET https://services.odata.org/TripPinRESTierService/Airports('KSFO')/Name

Используйте фильтр для запроса:

GET https://services.odata.org/TripPinRESTierService/People?$filter=FirstName eq 'Scott'

изменить данные:

POST https://services.odata.org/TripPinRESTierService/People
header:
{
	Content-Type: application/json
}
body:
{
    "UserName":"lewisblack",
    "FirstName":"Lewis",
    "LastName":"Black",
    "Emails":[
        "lewisblack@example.com"
    ],
    "AddressInfo": [
    {
      "Address": "187 Suffolk Ln.",
      "City": {
        "Name": "Boise",
        "CountryRegion": "United States",
        "Region": "ID"
      }
    }
    ]
}

удалить данные:

DELETE https://services.odata.org/TripPinRESTierService/People('russellwhyte')

обновить данные:

PATCH https://services.odata.org/TripPinRESTierService/People('russellwhyte')
header:
{
	Content-Type: application/json
}
body:
{
    "FirstName": "Mirs",
    "LastName": "King"
}

Суммировать

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

Эта статья была включена вwoohoo.floydpress.com/01-rest-hotwater…

Самая популярная интерпретация, самая глубокая галантерея, самые краткие уроки и множество трюков, о которых вы не знаете, ждут вас!

Категории