web-dev-qa-db-ja.com

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

RESTfulサービスを使用すると、リソースを作成、読み取り、更新、および削除できます。データベースアセットのようなものを扱う場合、これはすべてうまく機能しますが、これはストリーミングデータにどのように変換されますか？ （またはそうですか？）たとえば、ビデオの場合、各フレームを1つずつ照会する必要があるリソースとして扱うのはばかげているようです。むしろ、ソケット接続をセットアップし、一連のフレームをストリーミングします。しかし、これはRESTfulパラダイムを壊しますか？ストリームを巻き戻しまたは早送りしたい場合はどうすればよいですか？ RESTfulパラダイム内でこれは可能ですか？そのため：ストリーミングリソースはRESTfulパラダイムにどのように適合しますか？

実装の問題として、私はそのようなストリーミングデータサービスを作成する準備ができており、それを「最良の方法」で実行していることを確認したいと思っています。この問題は以前に解決されたと確信しています。誰かが私に良い素材を教えてくれますか？

reststreamingtheory
96
JnBrymn

私は本当に 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>

クライアントは、GET /media/1.3gpを使用してHTTP経由でリソースにアクセスできます。 1つのオプションは、クライアントがリソース全体をダウンロードすることです- HTTPプログレッシブダウンロード 。よりクリーンな代替案は、クライアントがHTTP Range headers を使用して、チャンクでリソースにアクセスすることです。 1MBのサイズのファイルの2番目の256KBチャンクを取得する場合、クライアントリクエストは次のようになります。

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

範囲をサポートするサーバーは、 Content-Range header で応答し、その後にリソースの部分的な表現が続きます。

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でサーバーが応答する危険があります。

77
MicE