Сколько раз вам приходилось спорить с разработчиками...

о том, какой метод правильно выбрать, например, PATCH и PUT?

➖➖➖
Разработчики часто упираются и выбирают PUT, так как считают что PATCH небезопасный и очень рисковый.
Поэтому, давайте разбираться, чем эти запросы отличаются, почему разработчики часто боятся PATCH и как аргументировать его использование
Погнали 🚀
➖➖➖
PATCH и PUT: в чем разница?
🔘 PUT — это про замену всего объекта.
Если вы отправляете PUT, объект перезаписывается полностью. Все, что не указано в запросе, исчезнет.
Например, у нас есть данные о пользователе: Имя, почта, телефон и мы делаем такой запрос:
PUT /users/1
{
"name": "Alex",
"email": "alex@example.com"
}
После выполнения запроса объект user будет состоять только из переданных полей. Забыли указать phone? Он исчезнет.
🔘 PATCH — это частичное обновление объекта.
Вы отправляете только изменяемые поля и остальные остаются нетронутыми.
Например, нам надо поменять только почту у нашего пользователя:
PATCH /users/1
{
"name": "Alexey"
}
Поле name обновится, а email и phone останутся без изменений.
➖➖➖
Почему разработчики против PATCH?
✖ Сложная валидация
Нужно проверять только изменяемые поля, что усложняет разработку.
Например, мы обновляем поля phone и email и этот момент серверу нужно понять, а что делать с полем name?
Варианты:
- Удалить значение? (оставить name пустым)
- Вернуть ошибку, потому что поле не может быть null?
- Игнорировать изменение?
✖ Риск частичных изменений
Если запрос PATCH прерывается, объект может остаться в "неконсистентном" состоянии.
Например, мы начали обновлять телефон и почту. И телефон мы обновили, а при обновлении почты произошел сбой (например, блокировка БД). Тогда у нас телефон новый, а почта старая.
⚠ Поэтому PUT проще и понятнее.
С PUT разработчикам не нужно разбираться, какие поля менять, — они просто заменяют весь объект целиком.
➖➖➖
Почему PATCH лучше в некоторых случаях?
✔ Экономия данных
PATCH отправляет только изменяемые поля, а не весь объект. Это важно, если объекты большие или запросов много.
✔ Избежание потери данных
С PATCH вы не рискуете случайно затереть данные, как это может произойти с PUT, если клиент забудет указать одно из полей.
✔ Гибкость
PATCH позволяет обновлять только то, что нужно. Это логично, если изменения касаются одного или двух полей.
➖➖➖
Что делать, если все таки, вы как аналитик, понимаете, что тут нужен PATCH, а разработка настаивает на PUT?
Если вы понимаете, что PATCH необходим, то вам, как аналитикам, надо будет продумать:
- все валидации,
- обработку ошибок,
- транзакционность.
И если разработчикам такое дать, то скорее всего у них не останется выбора и они согласятся.
Но тут надо очень четко ориентироваться на то, а зачем вы все это делаете и действительно ли надо упираться, потому что треугольник: Качество, Время, Стоимость никто не отменял.
И в большинстве случаев у вас не будет время на продумывание всего этого добра, поэтому в этом вопросе я за эффективность!
И если PUT и PATCH будут примерно похожи и мы не потеряем в скорости и эффективности, у нас небольшой объект, который мы меняем и нет сложной вложенности, то я встану на сторону разработчиков.
А вы что думаете на этот счет?