Начнём с некоторых определений
Перед тем, как дать определение REST API, нужно ввести несколько общих определений.
Архитектурный стиль – это набор согласованных ограничений и принципов проектирования, позволяющий добиться определённых свойств системы
API (Application programming interface) - программный интерфейс приложения для взаимодействия с другими приложениями.
Вот теперь можно давать определение REST API.
REST API (Representational State Transfer, передача состояния представления) - архитектурный стиль разработки API веб-приложений или компонентов распределённого приложения, используя протокол HTTP.
Другими словами, REST API - это набор правил, позволяющий программисту добиться неких целевых свойств API своего приложения. Что же это за свойства?
Целевые свойства REST API
- Производительность
- Масштабируемость, выраженная в:
- простота **унифицированного** интерфейса
- лёгкость внесения изменений, т.е. способность эволюционировать, приспосабливаясь к новым требованиям
- надёжность / отказоустойчивость
- переносимость компонентов
Получается, что REST API потребовался, так как возникла потребность создавать производительные, надежные и легко поддающиеся изменению обмены между клиентом и сервером. За счёт чего же это достигается?
Принципы построения REST API
Существует 6 **принципов**, которым должен соответствовать REST-интерфейс:
- единый интерфейс - ресурсы должны быть однозначно идентифицированы посредством одного URL-адреса
- н-р: неверно чтобы для одно и того же объекта для разных HTTP-запросов были разные интерфейсы
GET ...\getusers
PUT ...\createusers
- верно - когда интерфейс один, а что делать определяется видом запроса
GET ...\users
PUT ...\users
- Всегда использовать клиент-серверное взаимодействие и разграничивать данные между ними
- пользовательский интерфейс и вопросы сбора запросов — на стороне клиента.
- доступ к данным, управление рабочей нагрузкой и безопасность — на стороне сервера.
- Использовать Stateless protocol (протокол без сохранения состояния) - в период, между запросами никакая информация о *состоянии* клиента на сервере не хранится
- Следствие: в запросе сервер должен получать всю необходимую информацию для выполнения этого запроса
- Использовать кэширование - все ресурсы должны разрешать кэширование, если явно не указано, что оно невозможно, следовательно, все ответы сервера должны иметь явные или неявные обозначения кэшируемых и не кэшируемых ответов
- Учитывать слои взаимодействия - система может быть многоуровневой, и как следствие клиент не может однозначно знать взаимодействует он напрямую с сервером или с промежуточным узлом
- Код по требованию (необязательное условие) - REST может позволить расширить функциональность клиента за счёт загрузки кода с сервера (апплеты или скрипты)
REST и RESTful - в чём разница?
Термин RESTful был введён, чтобы различать сервисы, построенные чётко по шести указанным выше требованиям, от тех, которые соблюдают только часть требований.
RESTful - это приложение, в котором соблюдаются все требования к построению архитектуры REST API. По поводу этого см. чуть ниже в раздел "Недостатки и критика REST API"
Стандарты REST API
Надо понимать, что REST - это не протокол, поэтому у него нет чёткого и единственного стандарта разработки. Единственное, что чётко прописано - транспортом REST-запросов является HTTP. Всё остальное (формат данных, интерфейса API и т.д.) - на усмотрение разработчика.
Недостатки и критика REST API
- завязка на HTTP, спецификация которого имеет свои ограничение
- иногда это приводит к тому, что приходит эмитировать поведение некоторых специфических методов
- ограничения выборки, наложенные создателем интерфейса API
- чрезмерная выборка - н-р: есть сервис, которые возвращает контактные данные пользователя. Нам надо получить только имя, но сервис настроен на возврат имени, телефона и т.д.
- недостаточная выборка - например сервис, упомянутый выше, возвращает только телефон по умолчанию, а нам нужны все доступные телефоны
- Отсутствие однозначного понимания, что такое RESTful. А без этой ясности сложно сравнить сервисы и дать однозначный ответ - правильно ли спроектирован сервис или нет.
- Достаточно ли использовать код HTTP-ответа 200 при создании записи или надо использовать 201?
- Достаточно ли использовать код HTTP-ответа 200 при обновлении записи или надо использовать 250?
REST API в 1С
Долго на этом останавливаться не буду, просто обзорно распишу. В 1С можно выделить следующие способы работы с REST:
- создавать свой REST API (метаданные "Общие - HTTP-сервис")
- обратиться к любому REST API (методы встроенного языка: HTTPСоединение, HTTPзапрос, HTTPОтвет)
- взаимодействовать с автоматически генерируемый REST-интерфейсом платформы (см. Автоматический REST-интерфейс через протокол OData)
Выводы
В данной статье я постарался дать определение и описание того, что такое REST API. Недаром говорят, что если хочешь до конца понять термин или технологию - постарайся рассказать о ней другому человеку, что в данной статье и проделано ^_^.
Напоследок отмечу, что главный плюс REST - это простота, именно поэтому он долгое время являлся самым популярным стандартом для организации взаимодействия клиента и сервера. Является ли он таким на данный момент, ответить сложно, ибо есть множество интересных альтернатив: старенький, но надёжный, SOAP, передовой GraphQL, RPC, JSON-pure API и многое другое.
