0

分散実行サーバーで作業しています。サーバーで HTTP ベースの REST API を使用することにしました。クライアントはサーバーに接続し、次に実行するタスクを取得します。明らかに、取得したタスクを「更新」して、一度だけ処理されるようにする必要があります。GET には副作用 (取得したリソースの状態の変更など) はありません。(リソースを更新するために) POST を使用することもできますが、リソースを取得する必要もあります。私は、POST がタスクを「要求済み」としてマークし、次に GET がタスクを取得済みとしてマークする URL を持つことができると考えています。残念ながら、再び GET に副作用があります。これは REST ではうまくいかないのでしょうか? 私はこれを行うための「関数」リソースを持っていても問題ありませんが、少し調査せずにパラダイムを放棄したくありません。

パット・オー

4

2 に答える 2

0

他に当てはまらない場合は、POST リクエストを使用することになっています。POST リクエストでリソースを返すことを妨げるものは何もありません。しかし、何か (この場合) がそのリソースに発生することが明らかになりますが、これは GET 要求を使用する場合には当てはまりません。

于 2013-02-16T19:39:00.223 に答える
-1

REST は単なる概念であり、必要に応じて実装できます。ユースケースは人それぞれ異なるため、「正しい方法」というものはありません。(はい、そこに定義された仕様があることは理解していますが、それでも好きなように行うことができます)この状況で、GETに副作用が必要な場合、副作用があります。自分が行ったこと (および場合によってはなぜそれを行ったのか) を適切に文書化するようにしてください。

ただし、複数のサブスクライバーでキューを作成しようとしているように思えます。サブスクライバーが自動化されている場合 (スクリプトや他のマシンなど)、実際のキューを使用して確認することをお勧めします。( http://www.rabbitmq.com/getstarted.html )。

これを使用して Web UI や、実際の人がこれを処理する何かを強化する場合は、キューを使用して、GET リクエストでキューから次のアイテムを取得するだけです。

ほとんどのメッセージング システムを使用する場合、メッセージがキューからプルされる順序を保証できないことに注意してください。そのため、順序が必要な場合、このアプローチを使用できない場合があります。

于 2013-02-15T17:34:49.587 に答える