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

时间:2011-01-28 17:40:32

标签: rest streaming theory

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

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

1 个答案:

答案 0 :(得分:74)

我没有找到关于真正RESTful streaming的材料 - 似乎结果主要是将流媒体委托给另一个服务(这不是一个糟糕的解决方案)。所以我会尽我所能来解决它​​ - 请注意,流式传输不是我的域名,但我会尝试添加2美分。

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

  1. 访问媒体资源(元数据)
  2. 访问媒体/流本身(二进制数据)
  3. 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中提供的选项
    3. 我认为前者是更有效的选择,虽然它需要专用流媒体服务(和/或硬件)。它可能有点处于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访问资源。一种选择是客户端下载整个资源 - HTTP progressive download。更简洁的替代方案是客户端使用HTTP Range headers以块的形式访问资源。为了获取1MB大的文件的第二个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的服务器响应的风险。