#клиент-сервер #архитектурный-стиль

Representational State Transfer (Передача представительского статуса) — является архитектурным стилем для обеспечения стандартов между компьютерными системами в сети, что облегчает для систем обмен данными друг с другом

Как эффективно использовать HTTP, как лучше строить API

HTTP/1.1 или HTTP/2.

Темы

• Async REST

RESTful

Концепции

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

код на стороне клиента может быть изменён в любое время без ущерба для работы сервера и наоборот

Многослойность ситемы / Многоуровневость

Внутри сервера может быть обращение к другим серверам

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

Состояние не хранится на сервере

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

не увидев предыдущих сообщений

Клиент должен отправлять полню информацию

Единообразный унифицированный интерфейс

CRUD

## Взаимодействие между клиентом и сервером

Отправка запросов

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

• НТТР-метода, который определяет вид операции;

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

• пути к ресурсу;

• необязательного тела сообщения, содержащего данные.

4 основных метода НТТР

• GET — получение конкретного ресурса (по id) или коллекцию ресурсов;

• POST — создание нового ресурса;

• PUT — обновление конкретного ресурса (по id);

• DELETE — удаление конкретного ресурса по id;

GET, POST кэшируем

PUT, DELETE не кэшируем

В заголовке запроса клиент отправляет тип контента, который он может получить с сервера. Это Accept. Оно обеспечивает, что сервер не посылает данные, которые не могут быть поняты или обработаны клиентом. Параметры типов контента — это типы MIME или Multipurpose Internet Mail Extensions

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

• image — image/png, image/jpeg, image/gif;

• audio — audio/wav, audio/mpeg;

• video — video/mp4, video/ogg;

• application — application/json, application/pdf, application/xml, application/octet-stream.

GET/news/123

Accept: text/html, application/xhtml

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

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

Коды ответов

• GET — return 200 (OK)

• POST — return 201 (CREATED)

• PUT — return 200 (OK)

• DELETE — return 204 (NO CONTENT)