6

REST API の 1 つは、実行時間の長いプロセスを実行させます。クライアントを長時間待たせるよりも、すぐに応答を返したいと考えています。

それでは、この使用例を考えてみましょう。申請者が申請書を提出すると、最終的な結果が得られます。これは非常に大規模なプラットフォームであるため、アプリケーションをストレージに永続化することはできませんが、処理のためにキューに配置する必要があります。

この状況では、http://example.com/application/abc123のように、アプリケーションが最終的に存在する場所の URI を返すことは許容される慣行ですか?

同様に、アプリケーション リソースの表現の一部として、アプリケーションに関する決定を表す結果ドキュメントの URI を返すことは、許容される慣行でしょうか? 結果ドキュメントは数分間作成されず、その URI (またはアプリケーションの URI) への HTTP GET は、永続化されるまで 404 になります。

このような状況でのベストプラクティスは何ですか? リソースの「将来の」URI を配布することは許容されますか?

4

2 に答える 2

8

このような設計に問題はないと思いますが、HTTP ステータス コードのリストを詳しく見て、応答を改善してください。IMHO 最初のリクエストは 202 Accepted を返す必要があります:

リクエストは処理のために受け入れられましたが、処理は完了していません。

最終的に結果が返される URL へのリクエストは、その間に 204 No Content (?) を返す必要があります。

サーバーはリクエストを正常に処理しましたが、コンテンツを返しません

もちろん、処理が終了すると、最終的に 200 OK が返されます。

于 2012-10-07T18:50:46.700 に答える
2

「RESTful Web サービスクックブック」より

問題

計算の実行やデータの検証などのタスクにリソースの抽象化を提供する方法を知りたい。

解決

処理関数をリソースとして扱い、HTTP GET を使用して、処理関数の出力を含む表現をフェッチします。クエリ パラメーターを使用して、処理関数に入力を提供します。

これには、処理機能を表す URI に対する GET 要求のみが必要です。あなたの例 ' http://example.com/application/abc123 ' URI。応答を返すときは、Tomasz によって既に提案されているように、現在持っている情報を含め、HTTP コードを使用して処理の状態を示します。

ただし...、後続のアプリケーション処理で何らかの方法でデータを保存または変更する場合は、このアプローチを使用しないでください。

GET リクエストに副作用があってはなりません。いずれにせよ、アプリケーションの送信によって (キューから処理された後であっても) 新しい情報/データが保存される場合は、要求の本文にアプリケーションのデータを含む PUT または POST 要求を使用する必要があります。詳細については、「HTTP GET 要求でデータを変更すべきではない理由」を参照してください。

アプリケーションのサブミットがデータを保存または変更する場合は、非同期処理のパターンを使用します: アプリケーションの詳細を含む POST または PUT 要求。

例えば

POST http://example.com/applications

これは、新しいアプリケーション リソースの URI と共に「201 Created」を返します。

また

PUT http://example.com/applications/abc123

「201 Created」を返し、

どちらも、その時点ですでにわかっているリソース情報も返します。

その後、新しいリソースの URI に対して GET 要求を安全に実行できます。これは、データ (これまでのアプリケーション処理の結果) のみを取得するためであり、GET の結果としてデータが保存または変更されることはありません。

アプリケーションの処理の進行状況を示すために、GET 要求は応答で特定のステータス コード (キューに入れられた、処理中、受け入れられた、拒否された) を返したり、HTTP 応答コードを使用したりできます。いずれの場合も、「200 OK」は、アプリケーションの処理が完了したときにのみ返されます。

于 2012-10-08T06:46:01.303 に答える