Если система может быть удобна выражена в категории "ресурсы и операции над ними" - то REST почти удобен.
Если (как обычно) не может быть - то нафиг он нужен.

утомляет этот спор вокруг религиозных доктрин
я:
- отправляю запрос на определенный URL
- этот URL у меня идентифицирует объект запроса
- действие, которое можно совершить, определяется комбинацией HTTP-метода и части URL если нужно (если различающей способности метода не хватает)
- в теле запроса в JSON находится контекст действия
- в результате действие выполняется
- получаю ответ

Всё. И мне пофигу, считаете вы это REST или нет.

Угу. Так как "перезатирание" - это не изменение.
Но вообще, в рамках ООП, нет никаких "изменений объекта" (да и CRUD), есть "отправить бизнес-осмысленное сообщение в объект".
А эта логика в REST вообще не укладывается

Да, под REST тут имею в виду RESTful (REST level 2+)
REST level 1 - это просто json over http by POST, там все нормально.

Ну, кстати, у тебя не получится "тело запроса" и GET одновременно )

и кто же мне помешает?
какой-нибудь тупой прокси, который "отрежет" тело?

оно работает в большинстве случаев

хотя и не должно

Угу, например. Или клиент не поддерживает.

Я приводил пример выше: PUT /object/:id/property Возможно это не трушный рест, конечно, я никогда к нему религиозно не относился и про уровни кажется первый раз сегодня услышал.

Для меня это вопрос удобства/понятности, чтобы минимизировать когнитивную нагрузку на разработчиков клиента и сервера.

хотя по стандарту можно. проблема в клиентах

По-моему нет. Кажется сталкивался с ситуацией, когда nginx на GET-запросе не проксировал body.

Это не про "команду изменения" и не про REST.
Лучше (и правильнее) POST /changeProperty

По стандарту - серая зона. Раньше было нельзя, теперь не гарантируется ничего.

вопрос удобства/понятности

почему тогда просто постом не кидать боди в удобный и понятный глагол, который описывает что делается?

Потому что когда у тебя API на 500 таких глаголов - документация превращается в ад. А REST сам себя структурирует как раз в силу структурности URI.

И для любой реализации клиента, конечно, концепция POST на все - гораздо удобнее.
Фактически, любой интерфейс однозначно превращается в http api

А кто мешает API структурировать? У тебя же нет в коде интерфейса на 500 методов, явно будет несколько сервисов, несколько разных API.

как же вы доки ЯП читаете тогда, стандартные библиотеки всякие

С разными точками входа? POST /service1 , POST /service2 ?