流资源如何适合RESTful范式？

借助RESTful服务，您可以创建，读取，更新和删除资源。当您处理诸如数据库资产之类的东西时，这一切都很好-但是这如何转换为流数据？（或者是？）例如，对于视频，将每一帧都视为一次应查询的资源似乎很愚蠢。相反，我会建立一个套接字连接并流处理一系列框架。但这是否打破了RESTful范式？如果我想倒带或快进该流怎么办？这在RESTful范式中是否可能？那么：流资源如何适合RESTful范式？

作为实现的问题，我准备创建这样的流数据服务，并且我想确保自己以“最佳方式”进行操作。我敢肯定这个问题已经解决了。有人可以指出我的好材料吗？

我没有找到有关真正的RESTful流的资料 -看来结果主要是关于将流委派给另一个服务的（这不是一个坏解决方案）。因此，我将尽力解决这个问题-请注意，流媒体不是我的业务领域，但我会尝试加2美分。

在流媒体方面，我认为我们需要将问题分为两个独立的部分：

1. 访问媒体资源（元数据）
2. 访问媒体/流本身（二进制数据）

1.）访问媒体资源
这是非常简单的，可以以干净和RESTful的方式进行处理。举例来说，假设我们将有一个基于XML的API，该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访问资源GET /media/1.3gp。一种选择是让客户端下载整个资源-HTTP渐进式下载。较干净的替代方法是让客户端利用HTTP Range标头来分块访问资源。为了获取文件的第二个256KB块（大小为1MB），客户端请求如下所示：

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。