Некашерно, нарушается SRP

В таком случае я вполне развернуто ответил

Не нарушается

Ответственность сохранить и все с ней хорошо и стабильно

Практически ноль причин для изменения этого метода (в контексте темы), потому он и сидит в фреймворке

не вижу причин использовать PATCH - разве что у тебя отправляются какие-то специфичные структуры которые преобразование данных описывают. Это оч специфично.

REST это не про апишки. Для апишек тебе хватит понятия идемпонетности из специфкации HTTP (полезно для обработки ошибок и ретраев) и концепции URI если вдруг хочешь юзать http кэширование (что скорее всего ты не захочешь юзать, проще кэш на уровне приложения организовывать если мы говорим про SPA/Mobile App. Http кэш красиво когда у тебя сервер рендрит инфу.

Не еби себе голову со всеми этими "рестами" и делай просто Json RPC over http. Всеравно у тебя именно это и выйдет. Хочешь ты того или нет. Как не притворяйся

даже http статус коды больше чем для ошибок транспорта не катят (что бы ретраи опять же было удобно делать)

Все норм выйдет

Если у тебя save сохраняет и обновляет, то это нарушение SRP

По факту этот метод большую часть времени обновляет. Сохранение это первый шаг. Если нечего обновлять, нужно сохранить. Я тоже не вижу тут нарушения.

Сохраняет и все

А добавляет или обновляет — решайте выше, когда сохраняетесь новый или имеющийся

Или ниже, подменяя реализацию, если нужно отойти от готового решения

Открыл Ворд. Создал документ. Написал строчку. Сохранил. Написал ещё строчку сохранил. Что может измениться в создании, что повлияет на способ сохранения?

все стардали этой хуйней.

нет если у тебя это PUT и он идемпотентен

Что странно, REST предполагает POST как создание записи, PATCH как изменение. И более того PUT который заменяет или создает новую запись

А споры про то нарушает save srp или нет😂

1. PATCH не входит в спецификацию HTTP 1.1 и как следствие утверждать что PATCH это "чет про REST" можно так же как утверждать что WebDAV это REST (и любая другая надстройка над http)
2. REST ничего такого не предполагает. REST (а точнее спека HTTP 1.1, которая входит в набор спецификаций для которых REST теоритическое обоснование выбранной модели) лишь вводит разделение что PUT должен гарантировать идемпотентность операции а POST не обязан ее гарантировать. При этом оба "не должны иметь тела ответа" но на это все забивают)

классическая проблема - корреляция между "реурсами HTTP" и "сущностями в базе". Вот на этом месте у большинства каша в головах которая приводит к сложным и неудобным апишкам и высокой связанности в коде.

Примеры "валидных" с точки зрения REST операций которые скорее всего людям тут покажутся "не рестфул же блиать"

POST /get-some-value-and-increase-counter
PUT /some-record/{id} - будет создавтаь и обновлять если уже есть
POST /record/{id}/increase-counter