Итак, что мне делать в моей ситуации?
Первый шаг - просмотреть реестр методов HTTP, который определен в RFC 7231
Дополнительные методы, выходящие за рамки данной спецификации, были стандартизированы для использования в HTTP. Все такие методы должны быть зарегистрированы в «Реестре методов передачи гипертекста (HTTP)», поддерживаемом IANA
Реестр в данный момент находится здесь: https://www.iana.org/assignments/http-methods/http-methods.xhtml
Таким образом, вы можете просмотреть методы, которые уже были стандартизированы, чтобы увидеть, имеет ли какой-либо из них соответствующую семантику.
В вашем случае вы пытаетесь передать запрос с телом сообщения. Как правило, запросы не просто идемпотент , но также безопасны .
Быстрый просмотр реестра может привести к рассмотрению ПОИСК
ПОИСК - безопасный метод; он не имеет никакого значения, кроме выполнения запроса и возврата результата запроса
Это похоже на хороший вариант, пока вы внимательно не прочитаете спецификацию и не заметите ограничения , касающиеся тела сообщения . Короче говоря, WebDAV, вероятно, не то, что вы хотите.
Но, может быть, что-то еще подходит.
Второй вариант - считать вашу идиому поиска протоколом. Вы POST (или PUT, или PATCH) идентификаторы на сервер, чтобы создать ресурс, а затем получить представление этого ресурса, когда вы хотите результаты.
Сам по себе это не совсем тот единственный звонок и ответ, который вам нужен. Что он делает, так это заставляет вас думать о том, как вернуть представление ресурса результата запроса. В частности, вы можете использовать Content-Location , чтобы сообщить посредникам, что тело ответа фактически является представлением ресурса.
Я знаю, что POST-запросы должны быть зарезервированы для запросов, которые не являются идемпотентными
Это не совсем верно. При выполнении запросов, которые соответствуют семантике другого метода, мы предпочитаем использовать этот другой метод, чтобы промежуточные компоненты могли использовать преимущества семантики: можно попробовать идемпотентный запрос, предварительно извлечь безопасный запрос и т. Д. Поскольку POST не предоставляет такие гарантии, клиенты не могут воспользоваться ими , даже если они применяют .
В зависимости от того, как вам нужно управлять пространством имен URI серверов источника, вы можете использовать PUT - концептуально запрос и результаты являются двойственными, поэтому их можно рассматривать как два разных представлений одного и того же. Вы можете управлять этим с помощью типов медиа - один для запроса, другой для ответа.
Это возвращает вас к идемпотенту, но не дает вам безопасности.
Я подозреваю, что безопасные запросы с полезными нагрузками всегда будут проблемой; заголовок Vary в HTTP не позволяет серверу объявить, что возвращаемое представление зависит от тела запроса (отчасти потому, что GET не должен иметь тело запроса), поэтому промежуточному компоненту будет трудно понять последствия кэширования тела запроса.
Я наткнулся на другой альтернативный метод из другого потока SO, который должен был туннелировать запрос GET, используя метод POST / PUT, добавив заголовок запроса X-HTTP-Method-Override. Как вы думаете, это законное решение моего вопроса?
Нет, я не думаю, что это решит вашу проблему вообще. X-HTTP-Method-Override (и его варианты написания) предназначены для туннелирования методов, а не для переопределения метода. X-HTTP-Method-Override: GET сообщает серверу, что у полезной нагрузки нет определенной семантики , что возвращает вас в ту же самую лодку, что и при использовании запроса GET.