[解決済み] ストリーミングリソースは、RESTfulパラダイムにどのように適合するか？

質問

RESTful サービスを使用すると、リソースを作成、読み取り、更新、および削除できます。 これはすべて、データベース資産のようなものを扱っているときにはうまくいきますが、ストリーミング データにはどのように変換されるのでしょうか。 (例えば、ビデオの場合、各フレームをリソースとして扱い、一度に一つずつクエリを発行するのは馬鹿げているように思えます。 むしろ、ソケット接続をセットアップして、一連のフレームをストリーミングします。 しかし、これではRESTfulのパラダイムが崩れてしまうのではないでしょうか。 ストリームの巻き戻しや早送りを行いたい場合はどうすればよいでしょうか。 これは、RESTfulパラダイム内で可能なのでしょうか？ そこで ストリーミング リソースは、RESTful パラダイムにどのように適合するのでしょうか？

実装の問題として、私はそのようなストリーミングデータサービスを作成する準備をしており、私がそれを"最良の方法"で行っていることを確認したいです。 この問題は以前に解決されたことがあると思います。 どなたか良い資料を紹介していただけませんか？

どのように解決するのですか？

本当に RESTful ストリーミング - に関する資料は見つかりませんでしたが、そのほとんどはストリーミングを別のサービスに委ねるというものでした（これは悪い解決策ではありません）。ストリーミングは私の領域ではありませんが、私は私の 2 セントを追加しようとします。

ストリーミングの側面では、問題を2つの独立した部分に分離する必要があると思います。

1. メディア リソース (メタデータ) へのアクセス
2. メディア/ストリーム自体へのアクセス (バイナリデータ)

1.) メディアリソースへのアクセス

これは非常に簡単で、クリーンでRESTfulな方法で処理することができます。例として、ストリームのリストにアクセスできるXMLベースのAPIを用意するとします。

GET /media/

<?xml version="1.0" encoding="UTF-8" ?>
<media-list uri="/media">
    <media uri="/media/1" />
    <media uri="/media/2" />
    ...
</media-list>

...また、個々のストリームに

GET /media/1

<?xml version="1.0" encoding="UTF-8" ?>
<media uri="/media/1">
    <id>1</id>
    <title>Some video</title>
    <stream>rtsp://example.com/media/1.3gp</stream>
</media>

2.) メディア/ストリーム自体へのアクセス

これはより問題のあるビットです。あなたはすでに質問の中で1つの選択肢を指摘しており、それはRESTful APIを介してフレームに個別にアクセスできるようにすることです。これはうまくいくかもしれませんが、私はそれが実行可能なオプションではないことに同意します。

という選択があると思います。

1. 専用のストリーミング プロトコル (例: RTSP) を介して専用のサービスにストリーミングを委ねる。
2. HTTP で利用可能なオプションの利用

が必要ですが、前者の方がより効率的な選択であると私は考えています。 専用のストリーミング サービス (および/またはハードウェア) が必要です。しかし、私たちのAPIはすべての面でRESTfulであり、専用のストリーミングサービスが統一インターフェース（GET/POST/PUT/DELETE）を順守していなくても、私たちのAPIは順守していることに注意してください。私たちのAPIは、GET/POST/PUT/DELETEによってリソースとそのメタデータを適切に制御し、ストリーミングサービスへのリンクを提供します（したがって、RESTの接続性の側面を順守しています）。

後者のオプションは HTTP経由のストリーミング - は、上記の方法ほど効率的ではないかもしれませんが、間違いなく可能です。技術的には、HTTP 経由であらゆる形式のバイナリコンテンツにアクセスできるようにすることとそれほど変わりません。この場合、私たちの API は HTTP 経由でアクセス可能なバイナリ リソースへのリンクを提供し、リソースのサイズについても助言します。

GET /media/1

<?xml version="1.0" encoding="UTF-8" ?>
<media uri="/media/1">
    <id>1</id>
    <title>Some video</title>
    <bytes>1048576</bytes>
    <stream>/media/1.3gp</stream>
</media>

クライアントはHTTPでリソースにアクセスするために GET /media/1.3gp . 一つの方法として、クライアントはリソース全体をダウンロードすることができます。 HTTP プログレッシブダウンロード . よりクリーンな選択肢は、クライアントがリソースを分割してアクセスすることで、HTTP 範囲ヘッダ . 1MB の大きさのファイルの 2 番目の 256KB のチャンクを取得する場合、クライアント リクエストは次のようになります。

GET /media/1.3gp
...
Range: bytes=131072-262143
...

レンジをサポートするサーバは、このように Content-Range ヘッダ で応答し、その後にリソースの部分的な表現が続きます。

HTTP/1.1 206 Partial content
...
Content-Range: bytes 131072-262143/1048576
Content-Length: 1048576
...

我々のAPIはすでにクライアントにファイルの正確なサイズをバイト単位で伝えていることに注意してください(1MB)。クライアントがリソースのサイズを知らない場合、最初に HEAD /media/1.3gp を呼び出し、サイズを決定する必要があります。 416 Requested Range Not Satisfiable .