rest - 流媒体资源如何适应 RESTful 范式？

Question

使用 RESTful 服务，您可以创建、读取、更新和删除资源。当您处理数据库 Assets 之类的东西时，这一切都很有效 - 但这如何转换为流数据呢？ (或者确实如此？)例如，就视频而言，将每一帧视为我应该一次查询一个的资源似乎很愚蠢。相反，我会建立一个套接字连接并传输一系列帧。但这是否打破了 RESTful 范式？如果我想要快退或快进流怎么办？这在 RESTful 范式中可能吗？那么:流资源如何适应 RESTful 范式？

作为实现方面的问题，我正在准备创建这样的流数据服务，并且我想确保我正在以“最佳方式”进行操作。我确信这个问题以前已经解决了。有人能给我指点好的 Material 吗？

Answer 1

我没有找到关于真正RESTful streaming的资料- 结果似乎主要是将流媒体委托(delegate)给另一个服务(这不是一个糟糕的解决方案)。所以我会尽力自己解决这个问题 - 请注意，流媒体不是我的领域，但我会尝试添加我的 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. 通过专门的流媒体协议(protocol)(例如 RTSP)将流媒体委托(delegate)给专用服务
2. 利用 HTTP 中可用的选项

我相信前者是更有效的选择，尽管它需要专用流媒体服务(和/或硬件)。这可能有点接近 RESTful，但请注意，我们的 API 在所有方面都是 RESTful，即使专用流服务不遵守统一接口(interface) (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 访问资源。一种选择是客户端下载整个资源 - HTTP progressive download 。一个更干净的替代方案是客户端使用 HTTP Range headers 分块访问资源。 。为了获取 1MB 大文件的第二个 256KB block ，客户端请求将如下所示:

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。