Как-то не очень представляю себе учебник по rest. Тут собственно одного понимания что это такое хватает.
Ну если хочешь учебник возьми любой по HTTP например - самый rest из всех rest'ов :) Да и автор rest (не помню как его звать) описал эту фигню параллельно работая над спецификацией HTTP 1.1.

А архитектурные ошибки... Ну пожалуй единственная ошибка которую я могу себе представить это разнородность стилей запросов.
Например можно сделать запросов клиентов через GET .../getclients&name%20like%20..... И рядышком запрос товаров через POST ../getstuff а параметры запроса передавать как json в теле post-запроса. Что самое смешное это даже не ошибка, работаю с такими системами и сейчас, но раздражает когда пишешь к ним первого клиента. Потом превращаешь отдельные запросы в функции/классы/компоненты/итп и забываешь о самих запросах.

Bspleskтебе нужен api-guidelines:
Пример от microsoft:
https://github.com/Microsoft/api-guidelines/blob/vNext/Guidelines.md О! Про них то я и забыл.
Это яркий пример как не надо делать API. Меня там особенно убивают утверждения что client MUST do such and such.
С чего это вдруг клиент что-то должен??? Это сервер должен предоставить данные в ответ на запрос в однозначно интерпретируемом формате. А уж поймет ли клиент ответ или нет... Как собственно говоря сервер на это может повлиять???

Alibek B.У меня вопрос не столько по формированию и обработке http-заголовков и содержимого, сколько об общепринятых соглашениях.Так никто и не предлагает самому использовать http, Просто это самый древний и известный из ныне использующихся API следующих REST принципам..

Alibek B.object/command или command/object?Это совершенно не важно. Встречал и то и другое, проблем особых нет ни в одном из случаев. С другой стороны, лично мне более по вкусу третий подход, с выносом всего что нужно в тело POST запроса. Этот подход ИМХО легче модернизировать и расширять. Да и намного больше параметров для команды можно передать.

Alibek B. Когда возвращать ошибку в http-статусе, а когда в теле ответа? Успешный запрос всегда возвращать со статусом 200 или по контексту?Смотря какую ошибку. Просто учитывай что твой API будет использоваться из браузера и браузер может (и скорее всего будет) перехватывать http кода. Так что никаких 404 или 500 на нормальные обрабатываемые ошибки.
Но авторизацию вполне можно делать через 401/403, особенно если у вас в конторе имеется выделенный SSO сервер и клиент должен к нему зайти для начала работы.

Alibek B.Это все вопросы скорее общепринятых соглашений. Есть такие?Увы. Спецификации писались только для конкретных протоколов.

HettWhite OwlС чего это вдруг клиент что-то должен??? Это сервер должен предоставить данные в ответ на запрос в однозначно интерпретируемом формате. А уж поймет ли клиент ответ или нет... Как собственно говоря сервер на это может повлиять???

Хотя бы с того, что клиент отправляет запрос серверу и он должен быть понятным. Если он будет всякую ерунду на сервер отправлять, глупо, наверное, надеяться, что сервер ему должен что-то вразумительное отвечать. Не так ли?Не так.
Если сервер получил ерунду в запросе, то он отвечает "не понял запрос" и все. Это вполне вразумительный ответ на невразумительный запрос.

Но вообще-то я говорил о другом, мне жутко не нравится что в Микрософтовском руководстве есть множество "client MUST", Это руководство по написанию API а не закрытой системы. Клиент использующий API физически может использовать функции АПИ, но может и оборвать коннект - а если сервер пишется в соответствии с Микрософтовским руководством можно ожидать что клиент что-то там сделает и будет вызывать функции по порядку или в соответствии с ожиданиями сервера. Читай главы 6 и 9 например.

Никто не гарантирует что клиент будет написан правильно.