Здравствуйте, Shmj, Вы писали:

S>Как вы решаете когда параметр поместить в адрес а когда в тело запроса?
Параметры помещаются в путь тогда, когда они помогают найти объект. Вопрос о том, как устроена навигация, отдаётся на откуп архитектору.
Нужно будет искать студентов по фамилии — можно сделать /students/lastname/ivanov, возвращающий коллекцию студентов.
Внутри коллекции логично обращаться по ID /students/lastname/ivanov/1231231213.json

Когда мы возвращаем объекты в ответ на GET-запрос, имеет смысл отдавать полный набор атрибутов, независимо от пути.
Это позволяет упростить и унифицировать код клиента.

А вот когда мы передаём объект в PUT, возникают варианты.
По строгой REST-конвенции, надо передавать всё (т.к. PUT принимает представление полного ресурса).
Но я встречал довольно много расслабленных трактовок, в которых PUT принимает и частичный апдейт, т.е. ведёт себя как PATCH.
Особенно это популярно тогда, когда в представление объекта включается всякая readonly-информация из системы, или какие-то значения по умолчанию.
Ну, там, помимо LastName и FirstName, у нас будет DisplayName. Если его не передать явно, то оно будет установлено в LastName + FirstName. В строгой трактовке REST так делать нельзя — если клиент не передал DisplayName в PUT, это эквивалентно DisplayName = null, и надо уважать требование клиента.

С одной стороны, это усложняет обработку идемпотентности — отличать модифицирующий PUT от PUT, который создаёт объект с нуля, становится труднее.
С другой стороны, сильно упрощает пользование API для развесистых объектов, у которых большая часть вычислима по умолчанию.

В общем, если у вас не поддерживается PATCH, то я бы сделал ID, да и прочие атрибуты в PUT, опциональными.
А если PATCH есть, то можно кое-что и ужесточить.

При несоответствии значения ID в теле значению в пути, нужно отдавать код 409.