Хорошо, POST с пустым телом, передайте данные в ответе?

Question

Я хочу, чтобы клиент мог запросить (через HTTP), какой документ находится во главе выходной очереди сервера, при условии, что если поиск будет успешным, документ будет автоматически удален из очереди. На сервере не более одного клиента, но клиент может быть многопоточным. В очереди нет случайного доступа; только заголовок может быть извлечен (и удален). Я не нашел этот сценарий обсужден ни здесь, ни где-либо еще в Интернете. Вот различные подходы, которые я могу придумать:

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

(2) Клиент может отправить два запроса, GET для извлечения документа во главе очереди и DELETE (с пустым или неосведомленным URL), чтобы удалить документ во главе очереди. Но для этого требуются два вызова, которые могут вызвать различные проблемы, особенно если несколько потоков/процессов в клиенте пытаются получить файлы.

(3) Клиент может отправить запрос POST с пустым телом; если есть документ во главе очереди, сервер вернет ответ, чье тело содержит документ, а также удалит документ из очереди. Это несколько противоречит тому, что он не соответствует ментальной модели публикации данных и получает простой код возврата, но в остальном мне это нравится. Я не беспокоюсь о том, что ответ пропал в пути, и документ пропал без вести; Я ожидаю, что соединение будет достаточно безопасным для предотвращения этого.

Было бы неплохо, если бы был другой метод HTTP для обработки этой ситуации, но, поскольку нет, я думаю, что (3) - лучший подход. Согласен? Не согласен?

ОБНОВЛЕНИЕ: Добавлено (4) после прочтения сообщения Dan675 ниже.

(4) Клиент может отправить запрос DELETE, на который сервер может отправить ответ с документом в теле (и, конечно же, удалить документ из очереди). Опять же, это немного противоречит ожиданиям (обычно вы не говорите: «Удалите элемент поверх стека для меня, пожалуйста», когда вы хотите его получить), но он будет работать.

Answer 1

Это должно быть сделано в двух звонках, первым для получения, а затем для УДАЛЕНИЯ.

Если удаление выполнено успешно, запрос клиента действителен, иначе просто обработайте его, как если бы весь запрос не удался, и попробуйте снова получить то, что находится в верхней части очереди. Это вызовет некоторые дополнительные накладные расходы из-за неудачных запросов, но я бы не рекомендовал делать какие-либо другие варианты.

Я предполагаю, что другим способом сделать это было бы, возможно, сначала сделать PUT, чтобы отметить самый верхний элемент как «зарезервированный» в некотором роде, затем выполнить GET и DELETE. Таким образом, можно пройти эту очередь на стороне сервера и найти самый верхний элемент, который не является «зарезервированным».