Я не понимаю, почему GET не подходит для этой операции. Или это только причина "semanti c"?
Да, но семантика - это весь смысл.
Одно из важных ограничений REST архитектурного стиля - это унифицированный интерфейс ; идея, что все компоненты понимают сообщения одинаково. Что нам дает, так это возможность выполнять полезную работу с использованием компонентов общего назначения.
В HTTP (приложение, построенное в рамках ограничений этого стиля) это означает, что мы можем использовать браузеры, кеши и обратные прокси-серверы. и серверные инструментарии и т. д., смешивая и сопоставляя, как мы go. Все это работает, потому что все эти компоненты понимают, что запрос должен интерпретироваться, как описано в RF C 7230, и что маркер метода запроса является «основным источником семантики запроса» и т. Д. .
Семантика GET была определена, и мы все разделяем это определение. Формулировка определения несколько изменилась по сравнению с его ранними спецификациями, но семантика основы c была постоянной: этот GET эффективно доступен только для чтения, а тело сообщения не представляет интереса для semanti c.
Если вы хотите использовать метод HTTP, в котором тело сообщения является семантически значимым, то вам нужно либо ослабить некоторые ограничения GET (например, с помощью POST), выбрать другой стандартизированный метод, который лучше соответствует вашему сценарию использования. (см. Реестр методов IANA HTTP ) или путем определения (и, возможно, стандартизации ) собственного метода HTTP.
Основная проблема при попытке определить полезную нагрузку для ПОЛУЧИТЕ - в то время как ваш заказной клиент может знать, что делать, а ваш заказной ресурс может знать, что делать, промежуточные посредники общего назначения, скорее всего, совершат неправильную вещь (например, кэширование ответов без сбора информации в запросе). тело, или выбросить тело за ненадобностью).
Обратите внимание, что я информация, закодированная в target-uri , работает просто отлично; HTML формы с использованием метода GET и другие варианты шаблонов URI могут использоваться для построения target-uri из локальной информации, которую может интерпретировать сервер (конечно, пределы defacto для длины target-uri намного короче, чем пределы defacto по размеру полезной нагрузки; это не универсальное решение).