OANDA API開発チームは弊社のAPIユーザーに最高の経験をもたらすことができるように常に努力しています。 ここではAPIを最も効率的に利用するためのベストプラクティスを紹介しています。
これは複数のリクエスト・レスポンス間に跨ってTCP接続をアクティブに保持しておく方式です。 毎回TCPのハンドシェイクプロセスを実行する必要がなくなるので、2つ目以降のリクエストのレイテンシーが減ります。
もし貴方がHTTP 1.0クライアントを使用している場合、そのクライアントがkeep-aliveディレクティブをサポートしていることを確認の上、Connection: Keep-Aliveヘッダをリクエストと共に送信してください。
Keep-AliveはHTTP 1.1プロトコルに含まれており、対応するクライアントではほとんどの場合デフォルトで有効となっています。 ただし、貴方のアプリケーションがヘッダに別の値を設定しないよう注意する必要があります。
| アクション | ベースライン (Keep Alive無し) | Keep Alive 有効 | レイテンシー削減率 |
|---|---|---|---|
| Create Trade | 341.7ms | 117.8ms | 65.5% |
| Closing Trade | 340.3ms | 118.0ms | 65.3% |
| Get (100) Trades | 399.8ms | 236.9ms | 40.7% |
| Get (500) Trades | 559.5ms | 434.5ms | 22.3% |
アイルランドの顧客との試験の結果です。
それぞれの値は連続した50個のリクエストのレイテンシー中間値をベースとしています。
弊社は全てのREST APIリクエストに対して圧縮を有効にすることを推奨します。
内部テストの結果、ある種のリクエストにおいては圧縮されたレスポンスは非圧縮の場合と比較して10分の1のサイズにまでなりました。 テストは更にレスポンスのサイズの縮小が、レイテンシーの削減につながることも示しています。
レスポンスの圧縮を有効にするには、リクエストに HTTPヘッダとAccept-Encoding: gzip, deflateの値を設定して送信してください。
| アクション | 圧縮無効 | 圧縮有効 | レイテンシー削減率 |
|---|---|---|---|
| Get (50) Trades | 167.6ms | 66.7ms | 60.2% |
| Get (100) Trades | 232.1ms | 127.9ms | 44.9% |
| Get (500) Trades | 339.7ms | 157.1ms | 53.8% |
米国（カリフォルニア北部）の顧客との試験の結果です。
それぞれの値は連続した50個のリクエストのレイテンシー中間値をベースとしています。
全てのリクエストはKeep Aliveを有効にしています。
もしアプリケーションが同じリクエストを何度も繰り返し送信する場合は、レスポンスのサイズを大きく削減する効果のあるETagを使用することを強く推奨します。 詳細と使用方法については、こちらをご覧ください。
注意: ETagはレスポンスの圧縮と同時使用することはできません。
デフォルトでは/transactionsエンドポイントは直近の50件のトランザクションを送信します。 リクエストにcountパラメータを設定することで最大500件の直近のトランザクションが送信可能です。 しかし、このタイプのリクエストは1分間に1件という制限があります。
もしアプリケーションが直近のトランザクションへの迅速なアクセスを必要とする場合は、デフォルトの/transactionsエンドポイントに頻繁にリクエストを行いトランザクションデータを自分のローカルシステムにキャッシュすることを推奨します。 トランザクションのレスポンスに重複がないよう、後続のリクエストはminIdパラメータに最後に受信したトランザクションのIDを設定してください。
/alltransactionsエンドポイントは、ユーザーがトランザクション履歴を圧縮されたjsonエンコードファイル形式で取得することを可能にします。 このファイルは、アカウントの開設から直近の最後の取引日午後4時までの全てのトランザクションを含みます。 リクエストを送信してからファイルがダウンロードできるようになるまで、ある程度時間がかかります。 そのためこのエンドポイントは、トランザクションの履歴の抜けている部分を埋める場合にのみ利用することを推奨します。
このセクションはHTTPレートストリーミングにのみ関係します。
HTTP レートストリームは同一のアクセストークンで複数のコネクションをサポートしており、ユーザーは複数のクライアントをそれぞれ地理上の異なった拠点から接続することにより、レートストリームの冗長化が可能です。 その場合、特定のコネクションに対する再接続が他の接続中のコネクションに影響しないよう、弊社はセッションIDを利用してそれぞれのコネクションを識別することを推奨しています。 以下にその例を挙げます。
この例では、二つのクライアントが同一のアクセストークンを使用し、それぞれレートストリームを独立して受信しています:
クライアント1が”sessionId=Client1”をリクエストに設定し、レートストリームに接続してレートの受信を始めました。
クライアント2が”sessionId=Client2”をリクエストに設定し、レートストリームに接続してレートの受信を始めました。
クライアント2にエラーが起きました。
クライアント2はレートストリームに再接続する必要があり、”sessionId=Client2”をリクエストに設定して、再接続を行いました。
既存のクライアント2に接続していたレートストリームは切断され、クライアント2に新しいコネクションが接続されました。
この間クライアント1には何の影響もありませんでした。
備考: もしセッションIDが設定されなかった場合は、一番旧いコネクションが切断されます（つまりクライアント1)。