## REST - Representational state transfer

1. [Что такое REST архитектура?](https://github.com/sashakid/ios-guide/blob/master/Main/11_networking.md#что-такое-rest-архитектура)
2. [Что такое RESTful на самом деле](https://habr.com/ru/companies/hexlet/articles/274675/)
3. [Как проще всего выполнять запросы GraphQL в iOS](https://nuancesprog.ru/p/10269/)
4. [Mozilla HTTP](https://developer.mozilla.org/ru/docs/Web/HTTP)

## Что такое REST архитектура?

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

Рой Филдинг первым использовал термин REST в 2000 году в своей докторской диссертации «[Архитектурные стили и дизайн программных сетевых архитектур](https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm)». На момент публикации диссертации Всемирная паутина (Web) была уже очень популярна. Филдинг, по существу, шагнул назад и проанализировал черты, которые сделали Web более успешным, чем конкурирующие протоколы Интернета. Затем он выработал концепцию фреймворка для создания сетевой коммуникации, подобной браузеру. Так что REST — это общий набор принципов, характерных не только для Web. Он может быть применен к другим видам сетей, таким как встроенные системы. REST — не протокол, так как он не задаёт деталей реализации.


## Структура REST запросов

Запрос REST API от клиента к серверу всегда состоит из следующих элементов:

* **Endpoint (эндпоинт)** сервиса вашего проект - это адреса, к которым обращаются запросы, относящиеся к API. Пример: api/createContract

![NewFullURISchem](/pictures/ComputerScience/NewFullURISchem.jpg?raw=true)

* **Параметры** — передаются открытые данные в формате ключ=значение или в самом пути, которые чаще всего используются для сортировки и фильтрации данных. Делятся на параметры пути и параметры запроса:
    - Параметр пути (`{userId}`) в запросе `delivery.com/orders/{userId}/list`;
    - Параметр запроса (`orderId`) в запросе `delivery.com/orders/list?orderId=123456`;

* **Заголовки (headers)** — метаинформация (служебная/уточняющая/дополнительная информация), в формате ключ: значение. Определяется формат передаваемых данных, спецификация и версия протокола обмена и др. информация, необходимая для корректной обработки запроса. 

    Если для выполнения запроса требуется аутентификация, в заголовке передаются сведения о пользователе — логин, токен и т.п. **Заголовки не отображаются в пути запроса**.

* **Тело запроса (body)** — данные, имеющие отношение непосредственно к запросу (полезная нагрузка). 

    Данные в теле запроса могут передаваться в различных форматах, например:
    - JSON, XML
    - HTML
    - Бинарные файлы (картинки, видео, аудио и т.д.)




## Архитектура REST / Ограничения Филдинга

Необходимые условия для построения распределенных REST-приложений:

* Клиент-серверная архитектура;

* Сервер не обязан сохранять информацию о состоянии клиента;

* Каждый запрос должен явно содержаться указание о возможности кэширования ответа и получения ответа из существующего кэша;

* Клиент может взаимодействовать не напрямую с сервером, а с произвольным количеством промежуточных узлов (может не знать
об этом, за исключением случаев передачи конфиденциальной информации);

* Унифицированный программный интерфейс сервера. Филдинг приводил URI в качестве примера формата запросов к серверу, а в качестве примера ответа сервера форматы HTML, XML и JSON, различаемые с использованием идентификаторов MIME;

## REST API vs SOAP API vs GraphQL

На сегодняшний день есть 3 основных подхода к построению программного интерфейса веб-приложений: REST (RESTful) API, GraphQL и SOAP API:

* REST (от англ. Representational State Transfer – «передача состояния представления») обеспечивает общение между клиентом (как правило, это браузер) и сервером с помощью обычных HTTP-запросов ([GET, POST, PUT, DELETE и т. д](./2.3.1.4%20HTTP_Methods.md)), передавая информацию от клиента в параметрах самих запросов, информацию от сервера – в теле ответа (который может быть, например, JSON-объектом или XML-документом). **REST** является **архитектурным стилем, а не стандартом**.

* GraphQL - язык, в отличие от REST:

    > В отличие от REST, в GraphQL всего одна точка взаимодействия (endpoint) с бэкендом, т. е. неважно, что вы хотите запросить или изменить: клиент будет взаимодействовать с одной конечной точкой, одним URL

* SOAP (от англ. Simple Object Access Protocol – простой протокол доступа к объектам, вплоть до спецификации 1.2) характеризуется использованием HTTP(S)-протокола лишь как транспорта (чаще всего, методом POST). Все детали сообщений (в обе стороны – от клиента к серверу и обратно) передаются в стандартизованном XML-документе. SOAP может работать и с другими [протоколами прикладного уровня](/2%20ComputerScience/2.3%20Networking/2.3.2%20Web/2.3.2.3%20Protocols.md) (SMTP, FTP), но чаще всего он применяется поверх [HTTP(S)](/2%20ComputerScience/2.3%20Networking/2.3.2%20Web/2.3.2.3%20Protocols.md#http-hypertext-transfer-protocol-изначально-протокол-передачи-гипертекста---80й-порт). **SOAP** является **протоколом и имеет спецификацию**.


| REST | SOAP |
| --- | --- |
| Сервисы социальных сетей | Финансовые услуги |
| Социальные сети | Платежные шлюзы |
| Услуги веб-чата | Телекоммуникационные услуги |
| Мобильные услуги | |

> Таким образом, REST "говорит" - делай лучше так, как я говорю и будет тебе счастье, но если не хочешь, окей, твое право. SOAP, в свою очередь "говорит" - делай как я говорю или я не буду работать. 

---

[2.3.1.1 API Theme](./2.3.1.1%20API.md) | [Back To iTWiki Contents](https://github.com/eldaroid/iTWiki) | [2.3.1.3 URI URL URN Theme](./2.3.1.3%20URI\URL\URN.md)