支払いゲートウェイとRESTful API
Eコマース機能を提供するRESTful APIがあります。正しい実装を決定するのに苦労している1つの領域は、支払いの処理方法です。
次のURI GET .../checkout/{id}/paymentがあるとします。このリソースは、支払いを行うために送信する必要がある詳細情報をクライアントアプリケーションに提供します。リソース内の情報の詳細は、以下の実装によって異なります
実装1リソースには、カード番号、請求先住所などの基本的な支払いフィールドが含まれます。データはPOST .../checkoutを使用してAPIに送信されます/ {id}/payment。次に、APIは支払いゲートウェイ（Paypalなど）にリクエストを送信し、応答を待ってから、適切な応答をクライアントアプリケーションに送信します。
実装2リソースには、支払いゲートウェイ（Paypalなど）に直接リクエストを送信する方法の詳細が含まれています。クライアントは支払いをゲートウェイに送信し、応答を待ってから、POST .../checkout/{id}/payment。
私が抱えている問題は、どちらにも長所と短所があることです。
実装1 APIへの1つのリクエストにすべてが含まれているため、フェイルセーフな方法のほうがいいと思います。 APIは、支払いが処理されるとバックエンドテーブルを更新し、成功または失敗のステータスをクライアントに返します。 APIはゲートウェイに応答を送信しているので、受け取った応答が本物であることがわかります。
実装2では、APIは支払いを処理する必要がなくなりますが、クライアントに2つの要求を行う必要があります。 1つは支払いゲートウェイへ、もう1つは参照付きのAPIへ。さらに、ゲートウェイを呼び出さずにAPIで支払い参照を検証するにはどうすればよいですか？不正なクライアントはAPIに参照を送り返す可能性があり、それが誤って有料としてマークされる可能性があります。
私のアイデアをそこに捨てたかっただけですが、誰かが支払いゲートウェイとRESTful API Webサービスを実装するための本当に良い解決策を持っているとしたら、それは素晴らしいことです。
[〜＃〜] update [〜＃〜]実装について考えただけです。実際に、支払いを処理するための別の小さなAPIを作成することもできます。クライアントアプリケーションがapi.site.com/....にポストしないが、gateway.site.com/...にポストすることを除いて、実装1と同様に機能します。これにより、ある程度のセキュリティが得られます。私はgateway.site.comのコードを制御し、支払いプロバイダーが応答するのを待つことによってapi.site.comが妨げられないようにします。その後、ゲートウェイAPIは基本的にメインAPIのクライアントになり、支払い成功の詳細をAPIにポストします。
これについて何か考えはありますか？
私はあなたがあなたのサイトに大量のトラフィックがあることを期待していると思います。その仮定が正しければ、調整されたバージョンの実装を使用することになります。 api.site.comとgateway.site.comが2つの異なるサーバー上にある場合、DBを格納する3番目のサーバーもあり、両方のアプリで集中型DBを利用します。これにより、api.site.comとgateway.site.comがお互いについて知る必要がなくなり、すべての作業を指定された領域で維持できるため、デバッグがはるかに簡単になります。
そして、私の仮定が間違っている場合、私はImplementationの別の微調整されたバージョンに行くと思います。そのため、同じDBと通信し、すべてを同じサーバーに格納する2つの個別のアプリを作成します。これは基本的に私が上で言ったものですが、すべて同じサーバー上にあります。これにより、初期のオーバーヘッドが削減され、必要なときにスケーリングが簡単になります。
実装1が適しているプラットフォームを構築しているかどうか、またはそれが独自のeコマースプラットフォームである場合は、実装2の方が適しているかどうかに大きく依存します。
実装1複数の支払いゲートウェイを提供する場合は、スケーラビリティを考慮します。それらはすべて独自のREST APIと抽象化によりスケーラビリティを提供します。単一のゲートウェイがある場合、利点は後日支払いゲートウェイを変更できるという柔軟性です。これは今では一般的なことになります- a-days。ネットワーク関連の不具合やダウンタイムが発生した場合に備えて管理することもできます。何らかの形式でデータを保存している場合は、PCIコンプライアンスに対応する必要があります。
実装2可能な限り最速の方法で起動および実行し、PCIコンプライアンスに対処する必要はありません。ゲートウェイに対して2回目の呼び出しを行う必要があることに同意しましたが、これにより、トランザクションの有効性に関するセキュリティが提供されます。これは、支払いの処理に比べて高速です。
ほとんどの場合、実装1の方が適しています。保護するのが簡単で、おそらくデバッグ/ログ記録がはるかに簡単です。
私が実装2で抱えている大きな問題は、クライアントが支払いゲートウェイに直接接続するために、クライアントに資格情報を配布する必要があることです。一部のシステムではそれが可能かもしれませんが、私はすべてを疑っています。問題が発生した場所をデバッグするのもはるかに難しいと思います。たとえば、支払いがゲートウェイに送られても、2番目の確認投稿が届かない場合はどうなりますか？