取得が成功した場合、ドキュメントはキューから自動的に削除されることを理解した上で、クライアントがサーバーの出力キューの先頭にあるドキュメントを（HTTP経由で）要求できるようにします。サーバーごとに複数のクライアントが存在することは決してありませんが、クライアントはマルチスレッド化される可能性があります。キューへのランダムアクセスはありません。ヘッドアイテムのみを検索（および削除）することができます。私は、このシナリオがここで、またはWeb上の他の場所で議論されているのを発見していない。ここに私が考えることができる様々なアプローチがあります：空のボディをPOSTにして、応答にデータを渡しますか？
（1）クライアントはGET要求を送信できます。しかし、GETは副作用があるとは考えられていないので、これは良い考えのようには見えません。
（2）クライアントは、キューの先頭でドキュメントを取得するGETと、キューの先頭にあるドキュメントを削除するDELETE（空または無視されるURL）の2つの要求を送信できます。しかし、これは2つの呼び出しを必要とするため、特にクライアントの複数のスレッド/プロセスがファイルを取得しようとすると、さまざまな問題が発生する可能性があります。
（3）クライアントが空の本文を含むPOST要求を送信する可能性があります。キューの先頭に文書がある場合、サーバーは本文に文書を含む応答を返し、文書をキューからも削除します。これは、データを投稿して単純なリターンコードを受け取るという精神的モデルと一致しない点で、やや直感的ではありませんが、そうでなければ私はそれが好きです。私は、通過中に失われた応答と文書が欠落することを心配していません。私は接続がこれを防ぐのに十分安全であると期待しています。
この状況を処理する別のHTTPメソッドがあるといいですが、そうでないので、（3）が最良のアプローチだと思います。同意する？同意しない？
更新：下記のDan675の投稿を読んだ後、（4）を追加しました。
（4）クライアントはDELETE要求を送信することができます。この要求では、サーバーが文書内の文書との応答を送信できます（もちろん、文書をキューから削除することもできます）。繰り返しますが、これはやや直感的ではありません（通常、「スタックの上にあるアイテムを削除してください」と言わないでください）。
URLは常に同じですが、「アクション」ごとに異なるドキュメントを使用していますか？ – dash
はい、URLは常に同じです。はい、ドキュメントは毎回異なるはずです（複数の入力キューに同じメッセージが送信されない限り、これは防止できません）。 – Alan
私は1）が最も単純だが、意味的に間違っている、2）正しいが、実装がより複雑である、3）良い妥協であるが、まだ意味論的に間違っていることに同意する。 – dash