HTTPは、シナリオにぴったりの202ステータスコードを定義します。
202承認済み
リクエストは処理のために受け入れられましたが、処理は完了していません。リクエストは、実際に処理が行われるときに許可されない可能性があるため、最終的に処理される場合とされない場合があります。このような非同期操作からステータスコードを再送信する機能はありません。
202の応答は、意図的に非コミットです。その目的は、サーバーへのユーザーエージェントの接続がプロセスが完了するまで持続することを必要とせずに、サーバーが他のプロセス（おそらく、1日に1回だけ実行されるバッチ指向のプロセス）の要求を受け入れることができるようにすることです。この応答で返されるエンティティには、要求の現在のステータスの表示と、ステータスモニターへのポインター、またはユーザーが要求の実行を期待できる時期の見積もりが含まれている必要があります。
出典：HTTP1.1ステータスコード定義
これは201Createdと似ていますが、リクエストが完了しておらず、エンティティがまだ作成されていないことを示している点が異なります。応答には「注文リクエスト」を表すリソースへのURLが含まれるため、クライアントはこのURLを介して注文のステータスを確認できます。
あなたの質問にもっと直接的に答えるには：あなたは千里眼を求めているので、あなたがそれをする前に要求が成功するかどうかを「テスト」する方法はありません。
将来、リクエストを行おうとしたときに発生する可能性のあるさまざまな技術的な問題を予測することはできません。ネットワークが利用できない可能性があり、サーバーがデータベースまたは機能するために依存している外部システムにアクセスできない可能性があります。停電が発生し、サーバーがオフラインになっている可能性があります。漂遊ニュートリノがメモリに迷い込んで0にぶつかる可能性があります。 1にすると、壊滅的なカーネル障害が発生します。
リモートサービスを利用するには、他のプロセスとは別に、リクエストの失敗の可能性を考慮する必要があります。
特定の問題については、サービスにトランザクションの安全性がない場合、そこで何もベイクすることはできず、より現実的な方法でこれに対処する必要があります。私の頭のてっぺんからいくつかのオプション：
Tシャツ会社に「テスト」メカニズムを提供してもらうと、実際に注文しなくても、特定の注文を処理できるかどうかを確認できます。彼らとの注文は2段階の操作である可能性があります。この操作では、最初の段階で注文を作成し（その時点で、彼らはその作成を検証します）、その後、注文を処理するように依頼します（支払いを受け取った後）。正常に）。
最初にクレジットカードで支払いを行い、注文を「支払い済み」の状態に移行します。次に、非同期プロセスとしてTシャツサービスを使用して注文を処理しようとします。フルフィルメントが失敗し、顧客が何かを印刷しようとしたことが会社が作成する準備ができていないことを確認できる場合は、注文を変更するか払い戻しを行うために顧客に連絡する必要があります。
ほとんどの組織は、技術的な単純さとビジネスへのリスクの低減のために、2番目のアプローチを採用します。また、利用できないTシャツサービスに対応できるという利点もあります。非同期プロセスは、サービスが利用可能になるまで待機し、その時点で注文を完了するだけです。