Здравствуйте, Slicer [Mirkwood], Вы писали:

SM>Это означает, что поля из {id}/admin не входят в {id}?
Входят. GET и PUT так или иначе отличаются — к примеру, PUT должен игнорировать id, а GET не возвращать пароль

scf>>POST /user/{id}/password — смена пароля
SM>Это мне кажется неудачной идеей сразу по 3 причинам.

Натягивание REST на задачи реального мира, по моему опыту, требует, так сказать, дополнительных допущений:
— GET/PUT/POST на одном и том же ресурсе — несимметричны.
-- GET может не возвращать некоторые данные (пароль)
-- PUT может не передавать некоторые данные, которые возвращаются из GET (id, modifiedDate, опциональные поля)
-- POST может передавать как меньше, так и больше данных, чем GET
— не все операции упаковываются в CRUD. для дополнительных обычно используется схема POST /resource/{id}/operation_name
— обязательные параметры ресурса и операций указываются в Path, опциональные — в query string.
— PATCH используется редко, т.к. качественная его реализация сложна и делать ее приходится руками
— поэтому partial PUT и популярен — это эффективнее, чем GET+PUT. Но для этого нужен json фреймворк, который разделяет null и отсутствие поля в документе.
— Контроль прав доступа на уровне отдельных полей модели реализовать можно, но сложно, поэтому на каждый ресурс часто накручивают отдельные привилегированные операции

SM>Смотрите: 1) сначала мы точку для изменения количества данного товара сделаем /{id}/count, 2) потом окажется что нам нужно разные проверки осуществлять при покупке и продаже, и нам придется либо иметь отдельно /{id}/countForSell и /{id}/countForBuy, либо оставить только /{id}/count и тогда опять будет вопрос — как понять, идет ли речь об изменении количества в результате покупки товара или его продажи.

GET /{id}?filter=count
PUT /{id} //partial update for count
А если окажется, что обновление count — сложная операция, то:
POST /{id}/count {amount: 1, operation: "sell"}