Моя проблема в том, как это выглядит как служба REST.
Подумайте, как бы выглядел веб-сайт.
Вы бы начали с некоторого известного URI в вашем списке закладок. Выборка этой страницы даст вам представление формы, которая будет иметь элементы управления вводом, которые описывают, какие данные должны быть предоставлены (и, возможно, включают значения по умолчанию). Клиент предоставляет данные, о которых он знает, и отправляет форму. Данные в форме используются для создания HTTP-запроса, как описано в правилах обработки форм HTML. Ответ на этот запрос включает представление ответа или, возможно, следующую часть работы, которую необходимо выполнить.
Это ОТДЫХ .
Получение формы (через URI с закладкой) будет, конечно, GET; мы просто обновляем нашу локально кэшированную копию представления «текущий» форм. Отправка формы может быть GET или POST; нам не обязательно знать это заранее, потому что эта информация передается в представлении самой формы.
GET против POST включает ряд компромиссов. Семантически, GET является безопасным , это означает, что ресурс может быть выбран в любое время, что пауки могут его сканировать, что доступ к ресурсу таким образом является "бесплатным". Это здорово, когда ресурс свободен, потому что клиенты в ненадежной сети могут автоматически повторить запрос, если ответ потерян. С другой стороны, объявление миру о том, что запрос безопасен, когда на самом деле получение ответов является дорогостоящим, не является выигрышной игрой.
Кроме того, GET не поддерживает тело сообщения (точнее, полезная нагрузка не имеет определенной семантики). Это означает, что информация, предоставляемая клиентом, должна быть частью самого идентификатора целевого ресурса. Если вы имеете дело с конфиденциальной информацией, это может быть проблематично - не обязательно при передаче (вы можете использовать защищенный сокет), но, безусловно, при проверке того, чтобы URI с конфиденциальной информацией не регистрировался там, где могут быть утечки конфиденциальные данные.
POST поддерживает включение полезной нагрузки в запрос, но не обещает, что запрос безопасен, а это означает, что универсальные компоненты не будут знать, смогут ли они автоматически повторить запрос в случае потери ответа.
Учитывая, что вы не хотите использовать идентификатор пользователя в URI, это точка против GET, и поэтому в пользу POST.