Brightcove Media API は、Brightcove メディア ライブラリへの強力なアクセス機能を提供します。HTTP ベースの REST API をサポートする任意の数のプログラミング言語から、動画とプレイリストに関する情報を抽出し、動画とプレイリストを修正することもできます。
Brightcove プラットフォームが Web サイトやアプリケーションを確実に稼動させることに関して、お客様からのご信頼をいただいております。弊社では、悪用や独占を防ぐため全アクセス ポイントの保護を確実に行う必要があります。アクセスに制限がないと、この共有環境を一部のユーザーが使い尽くし、様々な対話の質や性能の大幅な低下を全ユーザーが経験する可能性があるからです。
これを念頭に置きながら、安心して Brightcove サービスと対話できるアプリケーションを開発する方法を理解することは重要です。Brightcove Media API を使用した開発を支援するために、このドキュメントではできるだけ堅牢になるようにシステムを保護するための実装したメカニズムを概説します。また、エンド ユーザーがお客様の期待するサービス品質を享受できるように、アプリケーションを安全で信頼できるものにするための手順も紹介します。
できるだけ堅牢な統合化を行うには、連続的にアプリケーションを開発する必要があります。アプリケーションで複数の要求をキューに入れて、そのキューを完了するまで Brightcove Media API に対してそれらの関数を次々に実行する、ということです。このような開発には、いくつかの長所があります。特にインターネット上でのファイル転送が必要な create_video メソッドなど、重い要求に有効です。
アップロードを Brightcove Studio メディア モジュールがどのように処理するのかと同様に、ファイルを同時に 1 つずつアップロードすると、利用可能な帯域幅全体を使用して個々のファイルを転送できます。これにより、転送中のネットワーク中断が最小限に抑制され、中断が起こった場合でも、その影響は、複数ではなく単一のファイルに限定されます。
Brightcove システムが要求を受領した後に、アプリケーションが問題の予防や問題からの回復の方法を既知している必要があります。アプリケーションに信頼できるフィードバックを提供するために、Media 書き込み API の使用中に予想通りにアクションが完了しない場合、適切に対応するために使用できる詳細なエラー コードを構築しました。
処理すべき最も重要なエラー コードの 1 つは 213 – ConcurrentWritesExceededError です。このエラーは、同時に実行している他の Media 書き込み API 要求のために、Brightcove システムが処理できない Media 書き込み API 要求に返されます。Media API を使用して要求を実行するために、待ち行列システムを利用しないアプリケーションでは、このエラーが発生する可能性があります。アプリケーションを複数のユーザーが使用している場合、様々なユーザーがタスクを同時に実行するときに、このエラーはさらに発生しやすくなります。
上で説明したように、連続的にアプリケーションを構築すると、アプリケーションでこのエラーが発生するのを防ぐことができます。ただし、組織の他のアプリケーションが同時に動作している場合には、このエラーが発生することがあります。競合の可能性があるので、このエラーから回復できることは重要です。Brightcove サービスと統合するのは、このアプリケーションのみであることが分かっていても、将来も機能するように、アプリケーションにリトライ ロジックを含めてください。
エラー状態から回復できるようにアプリケーションを構築することは、非常に重要です。リトライ ロジックを実装すると、アプリケーションは、手動介入なしで回復が可能かもしれないエラーを生成した要求を再試行できます。ほとんどの場合、リトライ ロジックは、Brightcove サービスから受領した応答を点検する簡単なものです。応答が 213 エラーなどのエラーである場合、同じ呼び出しを再試行すれば、要求が受理される場合があります。リトライ ロジックを開発する場合、試行の数を制限し、成功の可能性を向上させるため、試行と試行の間への遅延の追加を考慮する必要があります。
リトライ試行をトリガするエラー メッセージが多くてはいけません。API が誤用されるとエラーメッセージが報告され、リトライ試行にもかかわらず同じエラーを必ず返すことが起こります。これらの要求を再試行する代わりに、今後このようなエラーを防ぐためにアプリケーションを更新する必要があります。このタイプのエラーの例は 210 InvalidTokenError です。このようなエラーは手動介入が必要なので、リトライを行う価値がありません。
リトライ試行とリトライ試行との間に遅延を加えることも推奨します。場合によっては、リトライ試行間に短い遅延を加えると、2 番目の試行の成功する確率が大幅に高くなります。リトライ試行間の遅延の実際の時間は、ほんの数秒にするべきです。ただし、行う要求のタイプを考慮し、アプリケーションに適切な時間を決める必要があります。
この種のリトライ ロジックを構築する方法を示すコードの例は、Media 書き込み API: PHP の例－動画をアップロードするを参照してください。