Что же такое REST API? Разберем для начала понятия REST и API по отдельности.

REST (Representional State Transfer / Передача состояния представления) - архитектурный стиль взаимодействия компонентов распределенного приложения в сети. То есть REST это по сути, набор ограничений которые должны быть выполнены при проектировании распределенной системы. И если веб-службы данной системы не нарушают ограничений REST, такие службы называют RESTfull.

API (Application Programming Interface / Программый интерфейс приложения) - описания способов которыми одна компьютерная программа может взаимодействовать с другой.

Соответственно REST API - это интерфейс (набор классов, функций, констант и т.д.) приложения который не нарушает ограничений REST, а таких ограничений всего 6, одно из которых не является обязательным. Пройдем кратко по каждому из них.

1. Модель клиент-сервер

Потребности интерфейса клиента должны быть отделены от потребностей сервера, хранящего данные.

Такое разделение:

• упрощает переносимость пользовательского интерфейса между платформами, так например клиент может быть реализован как для Desktop так и для мобильных устройств, может использовать различные front-end фреймворки и это никаким образом не отразится на серверной части.
• улучшает масштабируемость упрощая серверную часть.

2. Отсутствие состояния (Stateless)

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

Возьмем к примеру корзину интернет-магазина. Во время наполнения корзины клиентом мы не должны отправлять промежуточные состояния для временного хранения на сервер. Данные должны быть переданы единым запросом при оформлении покупки.

Данное ограничение дает следующие преимущества:

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

3. Кэширование

Как в WEB клиенты и промежуточные узлы могут выполнять кэширование ответов сервера. Ответы сервера на запросы должны явным или неявным образом включать метки, являются ли они кэшируемыми или нет.

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

Простым примером кэширования может выступить страница выбора продуктов интернет магазина. При обращении к данной странице впервые клиент запросит множество данных о продуктах. При этом изображения продуктов могут быть кэшированы, а вот цена продукта должна быть каждый раз запрошена заново, чтобы при ее изменении отобразить корректную величину. Соответственно изображения в данном случае являются кэшируемыми компонентами, данные о цене - нет.

4. Единообразный интерфейс

Унифицированные интерфейсы - фундаментальное требование REST сервисов. REST определят четыре ограничения для интерфейса:

1. Идентификация ресурсов. Все ресурсы идентифицируются в запросах с использованием URI в интернет системах. Ресурсы концептуально отделены от представлений возвращаемых клиентам. Например ресурсы могут хранится на сервере как записи в реляционной базе данных, при этом клиенту они будут переданы в виде представлений, к примеру JSON или XML.
2. Если клиент хранит представление ресурса, он обладает достаточной информацией для модификации или удаления ресурса. Например получив представление статьи блога в виде JSON:

{
  article: 
  {
    id: "1",
    author: "Author",
    title: .........
  }
}

клиент может сформировать запрос на изменение данной статьи либо ее удаление по идентификатору статьи указанному в поле id.

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

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

5. Разделение системы на уровни

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

6. Код по требованию (не обязательное ограничение)

Rest может позволить расширить функциональность клиента за счет загрузки кода с сервера в виде апплетов или сценариев.

Таким образом реализовав REST API мы получим следующие преимущества нашей системы:

• Портативность (за счет разделения клиент-сервер)
• Надёжность (исключается возможность утери информации благодаря Stateless);
• Производительность (за счёт использования кэша);
• Масштабируемость (построение многоуровневой системы);
• Прозрачность системы взаимодействия (особенно необходимая для приложений обслуживания сети);
• Простота интерфейсов;
• Гибкость. Легкость изменения для соответствия новым требованиям.

В следующей статье рассмотрим как реализуется REST API на практике с использованием Django REST Framework.