私の知る限り、OpenCPU にはタスク モデルがありません。つまり、リクエストが完了するまで、開いている TCP 接続で任意の時間待機する必要があります。
タスク モデルの実装の 1 つの可能性は、関数を実行したい場合200 OKに、リクエストのステータスを含む専用のタスク uri をすぐに返すことです。POST利点は、ジョブがバックグラウンドでサーバー上で実行されている間、クライアントがすぐに結果を取得できることです。
201 createdその後、クライアントは、ジョブが正常に終了したことを意味するが返されるまで、または失敗した呼び出しのエラー コードが返されるまで、タスク URI をポーリングします。成功した場合、本文には、POST今までに直接作成されたのと同じリソース リストが含まれます。
このモデルまたは同様のアプローチについての意見は? 誰もがこれをどのように処理しますか? TCP 接続を開かずに長時間実行されるジョブのサポートは価値があると思います。まだ実行中のジョブをポーリングしながら進捗情報を提供するなどのオプション機能も頭に浮かびます。
現在のバージョンの OpenCPU にはタスク マネージャーが含まれていないことは間違いありません。クライアントは、リクエストが完了するのを待っている間、接続を維持する必要があります。これにより、ほとんどのユースケースで API が適切かつシンプルに保たれますが、長時間実行されるジョブのスケジューリングには最適ではありません。ただし、すべての時間制限は構成可能であるため、ジョブが完了するまで 30 分待たされることはありません。
あなたが示唆するように、代替設計はAccepted 202、有効な POST 要求に戻り、クライアントに結果のステータスをポーリングさせることです。これは API へのクールな追加 (おそらくいつか追加される予定) ですが、クライアントとサーバーの実装がかなり複雑になります。
サーバーでは、タスク マネージャーを作成する必要があり、長時間実行される要求を監視、タイムアウト、および手動で強制終了する機能について心配することになるでしょう。さらに、関数がまだ実行されている間に R が提供できる情報はそれほど多くありません。たとえば、関数呼び出しが終了まであとどれくらいかを知る方法は実際にはありません。
可能なことの 1 つは、中間 stdout をキャプチャすることです。これにより、定期的に何らかのステータスを出力することで、R 関数に独自の進行状況インジケーターを実装できます。その後、クライアントは URL を繰り返し取得して stdout を読み取り、リクエストのステータスを問い合わせることができます。ただし、これがどれほど役立つかは疑問です。R 関数でプログレス メーターが表示されることはめったにありません (debug=TRUEまたは何かでない限り)。そのため、リモートで呼び出される R 関数でこれが異なるかどうかはわかりません。