オフライン (非リアルタイム モード) で 1 日 1 回 10,000 トランザクションを処理する必要があるという要件があります。
2つのオプションのどちらが望ましいですか
また
アーキテクトから、オプション 1 が望ましく、API はバッチ サイズが小さい場合にのみ意味があるとアドバイスされました。2 の欠点は、API を呼び出す人が、すべてのすぐに利用できる情報。
「2」がどのように実行可能なオプションになるかを知りたいので、ケースを作成するのに役立つコメント/提案は非常に役立ちます.
ありがとうラフル
これは完全な答えではありません。ただし、REST API を支持する理由の 1 つに言及したいと思います。それは検証です。これは、API を介してより適切に管理されます。ファイルが FTP の場所にドロップされたら、ファイルの形式を検証するのはユーザーの責任です。バウンスバックを説明するメッセージを付けて、「不良」ファイルをソースに戻すのは簡単ですか?
API 呼び出しで、受信した表現が有効なスキーマ (XML、json など) に準拠していない場合、サービスは「400 Bad Request」http ステータス コードで応答できます。これにより、サービスのコンシューマに有効な形式でデータを送信する責任が保持され、懸念事項をより適切に分離するのに役立ちます。
REST API の追加の理由:
ファイルにはトランザクションが含まれているため、各レコードはアトミックである必要があります (ファイル内のレコード間に関係があるなど、そうでない場合、それらのレコードは「トランザクション」と見なされるべきではありません)。したがって、ファイルを小さなバッチに分割するのは簡単です。
いずれにせよ、バッチでトランザクションを受け入れ、「202 Accepted」の HTTP ステータス コードで応答するサービスを定義できます。202 コードは、要求が受信され、非同期で処理されることを示します。したがって、応答には、個々のトランザクションのステータスを確認するためのコールバック リンクも含まれる場合があります。またはバッチ全体。その時点で、HATEOAS (Hypermedia as the Engine of Application State) を実装し、プロセス全体を自動化し、ステータスを報告できるようになります。
代わりにバッチ ファイルを使用すると、ファイルが事前のフォーマット検証チェックに合格した場合でも、各トランザクションを下流で個別に処理する必要があります。ロードされるレコードもあれば、ロードされないレコードもあります。私の推測では、ロードに失敗したレコードは引き続き処理する必要があります。また、成功したものと失敗したもののビューをユーザーに提供する必要がある場合もあります。現在、これはすべて REST API の外部で処理できます。ただし、API パターンは、この目的のためにシンプルでエレガントな私見です。