REST. Краткий обзор
REST (REpresentational State Transfer) – это архитектурный стиль, набор принципов проектирования, позволяющий добиться определённых свойств системы, таких как:
✹ Производительность
✹ Масштабируемость
✹ Гибкость к изменениям
✹ Отказоустойчивость
✹ Простота поддержки
🔹REST — это не протокол. Он не определяет правила о том, как мы должны передавать запросы, какая у них должна быть структура, что мы должны возвращать в ошибках. В качестве протокола использует REST HTTP.
🔹REST API (RESTful API) – это API, которые соответствует принципам REST.
🔹В архитектурном стиле REST нет ограничений по формату сообщений. REST API могут поддерживать любой формат сообщений, например XML, JSON, CSV, HTML и др.
🔹REST фокусируется на ресурсах, доступ к которым осуществляется через URL.
🔹Ресурс — это то, что доступно клиенту. Например, если мы пишем приложение для управления задачами, ресурсами могут быть Пользователь или Задача.
🔹Ресурс имеет свой адрес (URI), по которому его можно найти и запросить.
🔹HTTP-глаголы — это действия, которые можно выполнить над ресурсом. Например:
GET /schedule/speech/id413 — получить информацию об объекте с идентификатором 413
Принципы REST
1️⃣ Клиент-серверная архитектура – разделение зон ответственности между клиентом (кто использует API) и сервером (кто предоставляет API).
Преимущества:
+ Масштабируемость. Если растёт нагрузка на сервер, мы можем добавить ещё серверы
+ Простота поддержки и гибкость изменений. Если нам нужно внести изменения, мы можем сделать это на сервере, а клиент будет видеть изменения без каких-либо доработок на своей стороне.
Недостатки:
– Единая точка отказа в виде сервера.
– Увеличение нагрузки на сервер и сеть. Так как клиент будет совершать меньше каких-либо действий самостоятельно, вырастет количество запросов между клиентом и сервером.
2️⃣ Stateless – сервер не должен хранить у себя информацию о сессии с клиентом. Всю необходимую информацию для обработки клиент должен передавать в запросе. Сервер не может знать что-либо о предыдущих запросах от этого клиента.
Преимущества:
+ Масштабируемость. Когда запрос имеет всю нужную информацию для обработки, то можно сделать несколько одинаковых серверов-обработчиков: допустим, 10 вместо одного
+ Простота поддержки. Можно увидеть в логах, какое сообщение приходило от клиента и какой ответ он получил
+ Кэширование
Недостатки:
– Усложнение логики клиента. Именно на стороне клиента нам нужно хранить всю информацию о состоянии, о допустимых действиях, о недопустимых действиях и подобных вещах.
– Увеличение нагрузки на сеть. Каждый раз мы передаём всю информацию, весь контекст. Таким образом, больше информации гоняем по сети.
3️⃣ Кэширование
В оригинале это говорит о том, что каждый ответ сервера должен иметь пометку, можно ли его кэшировать. Кэширование снижает нагрузку на серверы и ускоряет получение ответа для клиента.
Однако это может быть достаточно сложно в реализации. Нужно учитывать, что если отдаём какие-то данные, которые сохранили раньше, то они могли устареть
4️⃣ Единообразие интерфейса. HATEOAS
Все запросы API к одному и тому же ресурсу должны выглядеть одинаково, независимо от того, откуда поступает запрос.
Hypermedia as the Engine of Application State (HATEOAS) — одно из ограничений REST, согласно которому сервер возвращает не только ресурс, но и его связи с другими ресурсами и действия, которые можно с ним совершить. Например, если мы запрашиваем информацию о книге с помощью GET /books/1, то сервер может вернуть действия, которые можно сделать с книгой, например, добавить в корзину.
5️⃣ Слоистая архитектура
Ни клиент, ни сервер не должны знать о том, как происходит цепочка вызовов дальше своих прямых соседей. Между клиентом и сервером могут находится балансировщики, прокси, кэши.
6️⃣ Код по требованию
Передача исполняемого кода от сервера клиенту. Это позволяет клиенту стать гибче
📎 Материалы
1. REST, что же ты такое? — статья и вебинар от Systems Education
2. Что такое REST API? — IBM
3. Бесплатный курс по документированию REST API
4. Серия видео Всё о REST API
#api #интеграции
REST (REpresentational State Transfer) – это архитектурный стиль, набор принципов проектирования, позволяющий добиться определённых свойств системы, таких как:
✹ Производительность
✹ Масштабируемость
✹ Гибкость к изменениям
✹ Отказоустойчивость
✹ Простота поддержки
🔹REST — это не протокол. Он не определяет правила о том, как мы должны передавать запросы, какая у них должна быть структура, что мы должны возвращать в ошибках. В качестве протокола использует REST HTTP.
🔹REST API (RESTful API) – это API, которые соответствует принципам REST.
🔹В архитектурном стиле REST нет ограничений по формату сообщений. REST API могут поддерживать любой формат сообщений, например XML, JSON, CSV, HTML и др.
🔹REST фокусируется на ресурсах, доступ к которым осуществляется через URL.
🔹Ресурс — это то, что доступно клиенту. Например, если мы пишем приложение для управления задачами, ресурсами могут быть Пользователь или Задача.
🔹Ресурс имеет свой адрес (URI), по которому его можно найти и запросить.
🔹HTTP-глаголы — это действия, которые можно выполнить над ресурсом. Например:
GET /schedule/speech/id413 — получить информацию об объекте с идентификатором 413
Принципы REST
1️⃣ Клиент-серверная архитектура – разделение зон ответственности между клиентом (кто использует API) и сервером (кто предоставляет API).
Преимущества:
+ Масштабируемость. Если растёт нагрузка на сервер, мы можем добавить ещё серверы
+ Простота поддержки и гибкость изменений. Если нам нужно внести изменения, мы можем сделать это на сервере, а клиент будет видеть изменения без каких-либо доработок на своей стороне.
Недостатки:
– Единая точка отказа в виде сервера.
– Увеличение нагрузки на сервер и сеть. Так как клиент будет совершать меньше каких-либо действий самостоятельно, вырастет количество запросов между клиентом и сервером.
2️⃣ Stateless – сервер не должен хранить у себя информацию о сессии с клиентом. Всю необходимую информацию для обработки клиент должен передавать в запросе. Сервер не может знать что-либо о предыдущих запросах от этого клиента.
Преимущества:
+ Масштабируемость. Когда запрос имеет всю нужную информацию для обработки, то можно сделать несколько одинаковых серверов-обработчиков: допустим, 10 вместо одного
+ Простота поддержки. Можно увидеть в логах, какое сообщение приходило от клиента и какой ответ он получил
+ Кэширование
Недостатки:
– Усложнение логики клиента. Именно на стороне клиента нам нужно хранить всю информацию о состоянии, о допустимых действиях, о недопустимых действиях и подобных вещах.
– Увеличение нагрузки на сеть. Каждый раз мы передаём всю информацию, весь контекст. Таким образом, больше информации гоняем по сети.
3️⃣ Кэширование
В оригинале это говорит о том, что каждый ответ сервера должен иметь пометку, можно ли его кэшировать. Кэширование снижает нагрузку на серверы и ускоряет получение ответа для клиента.
Однако это может быть достаточно сложно в реализации. Нужно учитывать, что если отдаём какие-то данные, которые сохранили раньше, то они могли устареть
4️⃣ Единообразие интерфейса. HATEOAS
Все запросы API к одному и тому же ресурсу должны выглядеть одинаково, независимо от того, откуда поступает запрос.
Hypermedia as the Engine of Application State (HATEOAS) — одно из ограничений REST, согласно которому сервер возвращает не только ресурс, но и его связи с другими ресурсами и действия, которые можно с ним совершить. Например, если мы запрашиваем информацию о книге с помощью GET /books/1, то сервер может вернуть действия, которые можно сделать с книгой, например, добавить в корзину.
5️⃣ Слоистая архитектура
Ни клиент, ни сервер не должны знать о том, как происходит цепочка вызовов дальше своих прямых соседей. Между клиентом и сервером могут находится балансировщики, прокси, кэши.
6️⃣ Код по требованию
Передача исполняемого кода от сервера клиенту. Это позволяет клиенту стать гибче
📎 Материалы
1. REST, что же ты такое? — статья и вебинар от Systems Education
2. Что такое REST API? — IBM
3. Бесплатный курс по документированию REST API
4. Серия видео Всё о REST API
#api #интеграции