Ответ 1
В основном вопрос заключается в том, являются ли определенные параметры частью идентификатора ресурса (URI) или нет. если это так, то вы бы использовали параметры запроса в противном случае пользовательские заголовки HTTP. Например, передача идентификатора album в музыкальной галерее должна быть частью URI.
Помните, например, что /employee/id/45 (или /employee?id=45, REST не имеет ущерба для параметров строки запроса или для чистых URI, разделенных косой чертой) идентифицирует один ресурс. Теперь вы можете использовать согласование содержимого, отправив заголовок запроса content-type: text/plain или content-type: image/jpg, чтобы получить информацию или изображение. В этом отношении ресурс считается одинаковым, а заголовок используется только для определения формата ресурса.
Как правило, я не большой поклонник пользовательских заголовков HTTP. Это обычно предполагает, что клиент уже имеет предварительные знания о реализации сервера (не обнаруживаемые с помощью естественных средств HTTP, то есть гипермедиа), которые всегда считаются анти-шаблоном REST
Заголовки HTTP обычно определяют аспекты HTTP , ортогональные к тому, что должно быть достигнуто в процессе запроса/ответа. Заголовок Authorization (действительно неправильный, должен был пройти аутентификацию) - классический пример.