Преимущества и недостатки RESTful API (часть 2)

Предыдущая публикация: Преимущества и недостатки RESTful API (часть 1)

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

Взаимодействие с разными ресурсами происходит единообразно, по общим правилам. Все ресурсы имеют чёткую структуру и единообразные URL-адреса. Запросы к API выполняются с использованием стандартных методов HTTP.

• Реализуется через:
  Использование стандартных HTTP-методов (GET, POST, PUT, DELETE)
• Представление ресурсов в виде URI (Uniform Resource Identifier, унифицированный идентификатор ресурса)
• Использование стандартизованных форматов данных (JSON, XML)
• Ответные сообщения должны быть информативными (код ответа)
• Поддержка HATEOAS (гипермедиа)

Где применяется:

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

Преимущества:

1. Простота использования при реализации взаимодействия с другими системами
2. Стандартизация упрощает интеграцию с другими системами
3. Однозначная обратная связь клиентам за счёт использования кодов состояния
4. Гибкость клиента к изменениям на стороне сервера (при использовании HATEOAS)

Недостатки:

1. сложность реализации специализированных вызовов: в случаях, когда выполнение операции возможно через один API, приходится использовать цепочку вызовов базовых методов для достижения того же результата
2. увеличение нагрузки на сетевое оборудование для передачи клиентских запросов со всей необходимой для выполнения информации
   увеличение нагрузки на сервер для реализации поддержки HATEOAS (гипермедиа) в ответных запросах
3. сложность реализации кэша по причине его зависимость от прав доступа у клиента (например, если это дополнительные данные, передаваемые в составе HATEOAS), а также настройки избирательности хранимых данных

Больше другой полезной информации в ТГ канале: https://t.me/all_for_analyse

5. Слоистая архитектура (Layered system)

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

Где применяется:

• в решениях с повышенными требованиями к безопасности данных - за счет разделения на слои предотвращается прямое взаимодействие с сервером, что позволяют лучше контролировать доступы к данным
• в решениях, где на уровне архитектуры различные функции (аутентификация, обработка данных, взаимодействие с БД) выполняются разными устройствами

Преимущества:

1. гибкость - архитектура решения позволяет безболезненно вносить в неё изменения, не влияющие на работу всех участников процесса
2. масштабируемость решения - за счет разделения клиентской и серверной части, можно расширять число подключенных серверов и приложения (в том числе и на промежуточных слоях) без необходимости внесения изменений в работу клиента и сервера
3. упрощение технической поддержки: любой сервер и приложение можно отключить / подключить без потери сервиса.

Недостатки:

1. увеличение нагрузки на сеть - каждый клиентский запрос проходит через всю цепочку вызовов (слои) от клиента к серверу и обратно в виде ответа
2. увеличение времени ответа - необходимость пересыла информации через большее число промежуточным узлов увеличивает время передачи запроса и ответа

Больше другой полезной информации в ТГ канале: https://t.me/all_for_analyse

6. Код по требованию (Code on done)

Суть: сервер в ответ на запрос клиента может отправить исходный код, который выполняется уже на стороне клиента.

Где применяется:

• в решениях, требующих реализации либкой логики на стороне клиента
• в решениях, где есть сложности с обновление клиентской части ПО

Преимущества:

1. гибкость реализации за счет того, что изменения достаточно внести только в логику сервера, далее исходный код отправляется клиенту с составе ответа и выполняется
2. для обновления решения (добавления нового функционала) не требуется обновление клиентской части решения, что упрощает внедрение нового функционала
3. снижение избыточности передаваемых данных за счёт того, что каждый клиент получает только необходимую ему функциональность (пример - пользователь с ролью администратор получает всю функциональность, а непривилегированный пользователь - базовый набор)

Недостатки:

1. безопасность - передача исходного кода от сервера к клиенту несет в себе риски перехвата и замены на вредоносный
2. совместимость - при наличии нескольких версий клиентского ПО, потребуется решать вопрос совместимости передаваемого кода
3. усложнение процесса тестирования за счет одновременной проверки работы как сервера, так и клиента после получения ответного сообщения
4. увеличение нагрузки на сеть за счет передачи кода в составе ответа
5. увеличение нагрузки на сервер для формирования ответа
6. увеличение времени ответа за счет доп. ресурсов сервера на формирование ответа

Вывод: каждый принцип имеет не только очевидные преимущества, но и недостатки, которые нужно знать и учитывать при планировании решения.

Однозначного ответа или рекомендации по их использованию не существует, так как кроме перечисленных выше, есть еще моменты с тонкостями реализации (технологии, поддержка, версионирование, квалификация команды и другие) и существующая (и будущая) ИТ инфраструктура, куда RESTFul нужно вписать.

Дополнительные материалы по теме статьи:

• Степени зрелости API RESTful
• HATEOAS в API - что за зверь?