Метод HTTP для использования при обработке клиентских данных для получения выходных данных

У меня есть требование добавить конечную точку в мой API для чтения большого зашифрованного входного файла и возврата некоторых расшифрованных метаданных из файла.

Идеальным решением для меня было бы использовать конечную точку GET и использовать зашифрованный большой двоичный объект в качестве параметра запроса, но меня беспокоят ограничения длины URI в разных реализациях.

Размещение данных в качестве параметра тела кажется плохой идеей (HTTP GET с телом запроса), не в последнюю очередь потому, что я беспокоюсь, что это нанесет ущерб решениям кэширования на стороне сервера, которые не ожидают никакой информации в теле GET.

Какой правильный метод HTTP следует использовать при получении данных от клиента и их обработке для получения вывода?

ОБНОВЛЕНИЕ Мои текущие мысли заключаются в том, чтобы взять данные в теле POST и вернуть 201 с заголовком LOCATION, содержащим URL-адрес GET, который ссылается на ресурс (т. е. расшифрованные метаданные). Поскольку сам ресурс никак не сохраняется, мне придется поместить метаданные в качестве параметра запроса в GET. Но поскольку длина метаданных ограничена (ограничение приложения), это не должно быть проблемой.


person Siddhu    schedule 30.12.2014    source источник


Ответы (2)


Я бы, конечно, избегал использования HTTP GET с телом запроса.

Для меня наиболее подходящим HTTP-глаголом будет POST. Если результирующий ресурс не будет сохранен, я бы не возвращал 201. Более того, в вашем приложении это может поставить под угрозу расшифрованные метаданные, которые теперь станут параметром строки запроса. Вместо этого просто верните 200 с содержимым, что вполне разумно для операции POST.

person ma499    schedule 30.12.2014

POST хорош, но не беспокойтесь о предложении заголовка LOCATION. Можно вернуть метаданные в теле ответа POST с кодом 200 OK.

Из RFC:

Действие, выполняемое методом POST, может не привести к получению ресурса, который можно идентифицировать по URI. В этом случае подходящим статусом ответа будет либо 200 (ОК), либо 204 (Нет содержания), в зависимости от того, содержит ли ответ объект, описывающий результат.

person tomtom    schedule 30.12.2014