部分的に成功した場合のAPI設計の休憩
だから私はチケット予約システムを持っています。
Apiでチケット予約リクエストがあります。アプリケーションから支払いサービスを呼び出します。
最初の試行で失敗した場合は、後で支払いを処理するためにキューにメッセージを追加します。そして、お客様にチケットを発行します。
キューから、支払いapiによる支払いを10分間に10回再試行します。成功しなかった場合、そのチケット予約レコードにステータスを追加し、オフラインで顧客からお金を受け取ります。
問題：クレジットカード詐欺により、このような予約が多数発生しています。
ソリューション：
私は解決策を考えています。支払い失敗時にチケットを発行するのではなく、別のhttpコードをクライアントに返したいのです。支払い以外のすべてのように成功です。
キューからのメッセージの処理中に、10回試行しても失敗した場合、クライアントにこのトランザクションが失敗したことを通知したいと思います。
パスした場合は、チケットの発行を続行するようにクライアントに通知します
質問：このソリューションには技術的な実現可能性がありますか？
HTTPリターンコードは、可能なすべてのリクエスト/レスポンスではなく、HTTPプロトコルを処理するように設計されています。
目を凝らした場合、大まかに、意図したとおりに解釈できるあいまいなコードを選択するのではなく、応答本文でより多くの情報を返すだけです
200 OK
{
"userCreation" : "Passed",
"ticketReservation" : "Passed",
"paymentProcessing" : "Failed"
"orderStatus" : "PendingPayment"
}
202 Accepted応答を返すことは、ここに適しています。
Wikipedia から：
リクエストは処理のために受け入れられましたが、処理は完了していません。リクエストは最終的に処理される場合とされない場合があり、処理が発生したときに拒否される場合があります。
このステータスは、現在正常に動作しているこのような場合のために予約されていますが、一部の帯域外処理が実行中であり、クライアントは後で確認する必要があります。
あらゆる種類の「帯域外」処理が発生する可能性があります。画像や動画をアップロードして最適化したり、クレジットカードによる支払いを処理したりするようなものです。
システムに別のオブジェクト、チケット購入リクエストを導入できます。
ユーザーがチケットを購入しようとすると、すぐにこれらのオブジェクトの1つを作成します（対応するIDの作成からの戻り）。
次に、呼び出し元は、以前に返されたIDを使用してGET/ticket-purchase-request/{ID}を呼び出して、このリクエストのステータスを監視できます。彼は、クレジットカード会社によってまだ検証されている、または失敗したというステータスを読み返すことができます。
クレジットカードのリクエストを自動的に再試行する理由がわかりません。それが失敗し、それが詐欺的な要求によるものであると言っている場合、私はもう一度試す理由はないと思います。再試行する唯一の理由は、一時的なエラー（ネットワーク接続やサーバーのビジーなど）によってクレジットカードの実行が失敗した場合です。クレジットカード会社から返されたステータスコードを確認する必要があります（拒否されたと言われた場合は、再試行しないでください）。
私は解決策を考えています。支払い失敗時にチケットを発行するのではなく、別のhttpコードをクライアントに返したいのです。支払い以外のすべてのように成功です。
疑問がある場合は、Webブラウザーでどのように機能するか考えてください。
ほとんどの場合、私たち（Webサイトの利用者）は、サーバーから返されるステータスコードにまったく注意を払いません。私たちが見るのはペイロードです。
ステータスコードの対象者は？一般化された機能をサポートするために提供されるメタデータを使用するgenericコンポーネント（ブラウザ、プロキシ、キャッシュ）。
ジムウェバー はこのように言った
Webはドメインではなく、ドキュメント管理システムです。すべてのHTTP動詞は、ドキュメント管理ドメインに適用されます。
ステータスコードについても同様です。それらはドキュメントに関するメタデータであり、標準化されたセマンティクスで一般的なコンポーネントは巧妙なことを実行できます。認証が必要なためログインダイアログをスローし、キャッシュされた表現を自動的に無効にし、ブックマークを無効にします。
つまり Ewan は正しい考えを持っています。つまり、消費者が必要とする情報をドキュメントに入れます。必要なユースケースをカバーできるように、メディアタイプとスキーマを定義します。リクエストに返信するときは、最初に送信する正しいドキュメントを計算し、、次にメタデータにどの情報を取り込むかを検討します。
これは、異常な使用例を回避するためのトリックパターンではありません。これは、HTTP APIが常に機能するはずの方法です。