Если коротко, то REST API — это способ взаимодействия сайтов и веб-приложений с сервером. Его также называют RESTful API.
REST API (где REST = Representational State Transfer = передача репрезентативного состояния, а API = Application Programming Interface = программный интерфейс приложения) — тип веб-сервиса, который использует HTTP-запросы для доступа к данным и управления ими. REST API — это ещё и набор архитектурных принципов, которые определяют, как можно передавать данные и управлять ими через Интернет.
Ключевой абстракцией информации в REST является ресурс. Ресурсом может быть любая информация, которую мы можем назвать. Ресурсом REST может быть, например, документ или изображение.
Ресурсы в REST API идентифицируются уникальным URI (Uniform Resource Identifier = унифицированный идентификатор ресурсов), а состояние ресурса представлено в чётко определённом формате, обычно JSON или XML. REST API опираются на набор методов HTTP, таких как GET, POST, PUT, PATCH и DELETE, для выполнения различных операций с этими ресурсами.
Один из ключевых принципов REST заключается в том, что он является stateless, что в буквальном переводе означает БЕЗ СОСТОЯНИЯ. Данное понятие означает, что сервер не хранит предыдущий запрос или, иначе говоря, предыдущее состояние системы. При подходе stateless в запросе серверу нужно каждый раз давать полную информацию, необходимую ему для предоставления ответа и завершения цикла. Этот принцип и заложен в названии REST — передача репрезентативного состояния. Благодаря этому REST позволяет системе быть
- лучше масштабируемой (можно создать несколько копий сервиса, и они все будут работать одинаково),
- более отказоустойчивой (она более простая),
- более гибкой (её легче изменять).
- более быстрой (ей не надо искать данные о прежнем запросе и не надо анализировать их).
Далее приводится полный список принципов.
Принципы REST API
REST API имеет шесть руководящих принципов, которые должны быть соблюдены, если интерфейс службы должен называться RESTful. Этими принципами являются:
- Единообразный интерфейс: Все запросы API к одному и тому же ресурсу должны выглядеть одинаково, независимо от того, откуда пришел запрос. REST API должен гарантировать, что один и тот же фрагмент данных, например, имя или адрес электронной почты пользователя, принадлежит только одному унифицированному идентификатору ресурса (URI). Ресурсы не должны быть слишком большими, но должны содержать каждый фрагмент информации, который может понадобиться клиенту.
- Разделение на клиент и сервер: При проектировании REST API клиентские и серверные приложения должны быть полностью независимы друг от друга. Единственная информация, которую должно знать клиентское приложение — это URI запрашиваемого ресурса; оно не может взаимодействовать с серверным приложением никакими другими способами. Аналогично, серверное приложение не должно изменять клиентское приложение, кроме как передавать ему запрашиваемые данные по HTTP.
- Без состояния (statelessness): REST API подход требует отсутствие состояния (= памяти о состоянии системы), а значит каждый запрос должен содержать всю информацию, необходимую для его обработки. Серверным приложениям не разрешается хранить какие-либо данные, связанные с запросом клиента.
- Кэшируемость: Когда это возможно, ресурсы должны кэшироваться на стороне клиента или сервера. Ответы сервера также должны содержать информацию о том, разрешено ли кэширование для доставленного ресурса. Целью является повышение производительности на стороне клиента при одновременном увеличении масштабируемости на стороне сервера.
- Многоуровневая архитектура системы: В REST API вызовы и ответы проходят через различные уровни. Как правило, не следует полагать, что клиентское и серверное приложения соединяются друг с другом напрямую. В коммуникационном цикле может быть несколько различных посредников. REST API должны быть разработаны таким образом, чтобы ни клиент, ни сервер не могли определить, общается ли он с конечным приложением или с посредником.
- Код по требованию (необязательно): REST API обычно отправляют статические ресурсы, но в некоторых случаях ответы могут содержать и исполняемый код (например, Java-апплеты). В этих случаях код должен запускаться только по требованию.
Хорошая статья на эту тему: REST, что же ты такое? Понятное введение в технологию для ИТ-аналитиков — по ссылке.