Спасибо за ответ.

scf>PUT /resource/{id} — поля, которые может менять владелец ресурса
scf>PUT /resource/{id}/admin — поля, которые может менять только админ
Это означает, что поля из {id}/admin не входят в {id}? То есть GET тоже нужно вызывать дважды — один раз для {id}, второй для {id}/admin? Ну ок, конкретно одну частную задачу вы решили — если над ресурсом разрешены два разных вида операций (привилегированные и обычные), вы разбиваете ресурс на два таких, для которых этой многовариантности нет. При условии, что это возможно.

scf>POST /user/{id}/password — смена пароля
Это мне кажется неудачной идеей сразу по 3 причинам. Во-первых, это почти то же самое, что PUT /user/{id} с указанием только password (partial put) — фактически мы заводим новое представление ресурса лишь только для того, чтобы хакнуть обычное представление и разрешить себе то, что мы бы хотели сделать при помощи partial put, но стеснялись, потому что partial put это нехорошо. По идее для этого есть более кошерный PATCH в основной ресурс, а не через введение нового ресурса. Во-вторых, POST??? Это выглядит так, словно мы создаем некий ресурс, а не изменяем. В-третьих, опять-таки в частном случае вы из положения вышли, хорошо. Но такой подход (опять-таки выделить кусок всего ресурса, который будет меняться данным POSTом) будет с ростом количества операций выглядеть все страннее. Смотрите: 1) сначала мы точку для изменения количества данного товара сделаем /{id}/count, 2) потом окажется что нам нужно разные проверки осуществлять при покупке и продаже, и нам придется либо иметь отдельно /{id}/countForSell и /{id}/countForBuy, либо оставить только /{id}/count и тогда опять будет вопрос — как понять, идет ли речь об изменении количества в результате покупки товара или его продажи.

Slicer