Полностью согласна с вами! Вы уловили суть компромисса :)
В нашем промышленном сценарии изменения действительно приходят точечно и асинхронно от разных датчиков и систем (как "несколько ячеек от разных пользователей"), поэтому паттерн PATCH оказался естественным и эффективным.
Насчёт GraphQL — интересная мысль. Мы смотрели в эту сторону для API потребителей данных, но для приёма событий от оборудования выбрали более простой RESTful-подход из-за его зрелости и простоты интеграции со legacy-системами. Но для фронтенда или агрегирующих сервисов — определённо да, GraphQL был бы отличным кандидатом.
Спасибо за важное замечание! Вы правы, если отправлять десятки запросов последовательно и без контроля, это создаст ненужную нагрузку.
В нашем случае ключевые детали:
Запросы отправляются пакетно и асинхронно, а не синхронно друг за другом.
На стороне клиента есть механизм троглинга (throttling), чтобы не создавать пиковой нагрузки.
Изменения часто приходят от разных источников событий (event-driven), и PATCH здесь логичнее для точечных обновлений.
Полная замена всего объекта (PUT) при каждом мелком изменении была бы избыточной в нашей событийной модели. Но ваш комментарий очень важен — без правильной реализации такой подход действительно может стать проблемой.
Полностью согласна с вами! Вы уловили суть компромисса :)
В нашем промышленном сценарии изменения действительно приходят точечно и асинхронно от разных датчиков и систем (как "несколько ячеек от разных пользователей"), поэтому паттерн PATCH оказался естественным и эффективным.
Насчёт GraphQL — интересная мысль. Мы смотрели в эту сторону для API потребителей данных, но для приёма событий от оборудования выбрали более простой RESTful-подход из-за его зрелости и простоты интеграции со legacy-системами. Но для фронтенда или агрегирующих сервисов — определённо да, GraphQL был бы отличным кандидатом.
Спасибо за важное замечание! Вы правы, если отправлять десятки запросов последовательно и без контроля, это создаст ненужную нагрузку.
В нашем случае ключевые детали:
Запросы отправляются пакетно и асинхронно, а не синхронно друг за другом.
На стороне клиента есть механизм троглинга (throttling), чтобы не создавать пиковой нагрузки.
Изменения часто приходят от разных источников событий (event-driven), и PATCH здесь логичнее для точечных обновлений.
Полная замена всего объекта (PUT) при каждом мелком изменении была бы избыточной в нашей событийной модели. Но ваш комментарий очень важен — без правильной реализации такой подход действительно может стать проблемой.