流式传输资源如何适应RESTful范式？

Question

使用RESTful服务,您可以创建,读取,更新和删除资源.当你处理像数据库资产这样的事情时,这一切都很有效 - 但这又如何转化为流数据呢？(或者是吗？)例如,在视频的情况下,将每个帧视为我应该一次查询一个资源的资源似乎很愚蠢.相反,我会设置套接字连接并流式传输一系列帧.但这会打破RESTful范式吗？如果我想能够快退或快进流怎么办？这是RESTful范式内的可能吗？那么:流媒体资源如何适应RESTful范式？

作为一个实施问题,我正准备创建这样的流数据服务,我想确保我这样做是"最好的方式".我相信这个问题以前已经解决了.有人能指出我的好材料吗？

Answer 1

我没有找到关于真正的RESTful流媒体的材料- 似乎结果主要是将流媒体委托给另一个服务(这不是一个糟糕的解决方案).所以我会尽我所能来解决它​​ - 注意流媒体不是我的域名,但我会尝试加上我的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.)访问媒体/流本身
这是更有问题的位.您已在问题中指出了一个选项,即允许通过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通过HTTP访问资源GET /media/1.3gp.一种选择是客户端下载整个资源 - HTTP渐进式下载.更清晰的替代方案是客户端通过利用HTTP Range标头以块的形式访问资源.为了获取1MB大的文件的第二个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.