Пустой запрос HTTP POST или GET для генерации случайного значения через HTTP API

В моем HTTP API одна из конечных точек должна возвращать случайно сгенерированное значение, и это значение будет связано с аутентифицированным вызывающим абонентом конечной точки. В настоящее время у меня есть следующая структура:

GET http://example.com/random-ticket HTTP/1.1
Authorization: Basic base64-encoded-basic-auth-value
Accept: application/json
Host: example.com

HTTP/1.1 200 OK
Cache-Control: no-cache
Content-Type: application/json; charset=utf-8
Date: Thu, 03 Oct 2013 07:25:56 GMT
Content-Length: 59

{"user-ticket":"Pfa42634e-1a2e-4a7d-84b9-2d5c46a8dd81"}

Выдается запрос GET для извлечения случайного значения. Тем не менее, HTTP GET вызовы должны быть идемпотентными, и моя реализация выше не подчиняется этому правилу. С другой стороны, Я не уверен, правильно ли выдавать HTTP POST-запросы с пустым телом сообщения.

Каков правильный способ выполнения этого типа операций с помощью HTTP-книги?

Ответ 1

Safe = > вызывает ли вызов результат изменения состояния на сервере.
Idempotent = > если несколько вызовов приводят к тем же изменениям на сервере.

Итак, вопрос заключается не в возвращаемых данных. Скорее это состояние сервера: поэтому, если ~~вы сохраняете это значение на сервере~~, это приводит к изменению состояния, тогда оно не подходит для GET. В противном случае, если это данные, которые возвращены, это нормально. Вызов /fooobar.com/... возвращает разные данные, если их вызывать через 10 минут.

Посмотрите на другой пример: Служба часов, которая возвращает текущее время. Каждый раз, когда вы совершаете вызов, вы получаете другое значение, но сам вызов не приводит к изменению состояния на сервере, поскольку состояние часов поддерживается отдельно. Поэтому использование GET здесь - хороший выбор.

Ответ 2

В HTTP нет ничего, запрещающего использование POST с пустым телом.

Кроме того, сообщение содержит представление, которое является заголовком body+. В вашем случае тело имеет длину 0, что отлично, и заголовки, которые идентифицируют пользователя.

См. обсуждение здесь - http://lists.w3.org/Archives/Public/ietf-http-wg/2010JulSep/0273.html

Ответ 3

Нет проблем с генератором случайных чисел с GET, поскольку не сохраняется состояние сервера. Таким же образом у вас может быть калькулятор, который принимает параметры и добавляет их при вызове GET. Вопрос о cachable интересен, хотя на самом деле не применяется к случайному генератору, поскольку ресурс по своей природе не кэшируется. Это все еще не меняет того факта, что он может быть разработан безопасным/идемпотентным способом.

Что касается POST без тела или даже с использованием параметров в строке запроса, это нормально. Главное в POST заключается в том, что это может привести к изменению сервера. Это не гарантировало, что это произойдет, но вы не можете предположить, что это будет не так, как с GET. Независимо от того, установлен ли какой-либо контент, не меняется тот факт, что может быть изменение. Например, представьте себе фиктивный ресурс "\ counter\increment". Каждый раз, когда вы выполняете POST, он будет увеличивать счетчик \counter. Я не отправил какую-либо полезную нагрузку, но я вызываю изменение состояния сервера, поэтому он должен быть POST или PUT.

Ответ 4

Вы должны использовать POST в этом случае, потому что, по desgin, вызовы GET могут быть кэшированы. Что касается пустого почтового тела, проблем нет. Аналогичные сценарии также обсуждаются в: POST с пустым телом, в котором в одном сообщении упоминается:

POST без длины контента, и никакое тело не эквивалентно POST с Content-Length: 0 и ничего не происходит, как это могло бы произойти, например, при загрузке пустого файла. Ресурс определяется URL-адресом, и сервер должен знать, как обращаться с телом, в том числе, если он пуст. Я не вижу здесь проблемы: -/

Вилли