ストリーミングリソースはRESTfulパラダイムにどのように適合しますか？

RESTfulサービスを使用すると、リソースを作成、読み取り、更新、および削除できます。これは、データベースアセットのようなものを扱うときにうまく機能しますが、これはどのようにストリーミングデータに変換されますか？（またはそうですか？）たとえば、ビデオの場合、各フレームを1つずつクエリする必要があるリソースとして扱うのはばかげているようです。むしろ、ソケット接続をセットアップして一連のフレームをストリーミングします。しかし、これは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で利用可能なオプションを利用する

前者の方がより効率的な選択だと思いますが、専用のストリーミングサービス（またはハードウェア）が必要です。それはRESTfulと見なされるものの端にあるかもしれませんが、私たちの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。1つのオプションは、クライアントがリソース全体をダウンロードすることです-HTTPプログレッシブダウンロード。よりクリーンな代替策は、クライアントがHTTP Rangeヘッダーを利用してチャンクでリソースにアクセスすることです。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。そうしないと、サーバー応答が発生するリスクがあります。