Эта статья представляет собой введение в RESTful веб-сервисы и краткий обзор REST и HTTP.

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

  • Введение в REST API — RESTful веб-сервисы
  • Различия REST и SOAP
  • Разработка REST API — что такое Contract First (контракт в первую очередь)?
  • Разработка REST API — что такое Code First (код в первую очередь)?
  • REST API — Что такое HATEOAS?
  • Рекомендации по REST API — примеры проектирования веб-сервисов на Java и Spring



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

Комментарии (12)


  1. xkondorx
    10.01.2020 10:01
    +2

    Тег не Java, а Http, Web или что-то в этом роде ну и таких статей выше крыши, слишком поверхностно.


    1. val6852 Автор
      10.01.2020 10:38

      Это введение к серии статей — подробности будут в следующих статьях.


      1. sshikov
        10.01.2020 10:53

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


        1. val6852 Автор
          10.01.2020 11:40

          Это перевод серии статей. Во втором абзаце указан перечень всех статей. Надеялся, что кому-то будет интерсно прочитаь это в одном месте.

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


          1. xkondorx
            10.01.2020 12:19
            +1

            И все-же в заголовке лучше написать «Часть 1», так сказать «для широких масс»


            1. val6852 Автор
              10.01.2020 14:20

              Спасибо! Учту в своих статьях. Но это перевод и хотелось не сильно отклоняться от оригинала.


          1. pOmelchenko
            10.01.2020 17:43

            Ок, но по этому списку никак не перейти, не используя поиск по сайту…


          1. sshikov
            10.01.2020 19:05

            Пардон, я как-то упустил, что это перевод. Но если у вас есть свое мнение по этому вопросу — переводчик тоже может его высказать, я думаю.


  1. pOmelchenko
    10.01.2020 10:43

    А можно в начале (каждой) статьи увидеть оглавление?


  1. tuxi
    10.01.2020 11:37
    +1

    На Хабре нашествие рефератов?


  1. arthuriantech
    10.01.2020 13:56

    Ресурс — это ключевая абстракция, на которой концентрируется протокол HTTP.

    Природа которой не ограничена.


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

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


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

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


    1. xkondorx
      10.01.2020 14:14

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