流资源如何适应 RESTful 范式? [英] How do streaming resources fit within the RESTful paradigm?
问题描述
借助 RESTful 服务，您可以创建、读取、更新和删除资源.当您处理诸如数据库资产之类的东西时，这一切都运行良好——但这如何转化为流数据?(或者是吗?)例如，在视频的情况下，将每一帧视为我应该一次查询一个的资源似乎很愚蠢.相反，我会建立一个套接字连接并流式传输一系列帧.但这是否打破了 RESTful 范式?如果我希望能够快退或快进流怎么办?这在 RESTful 范式中可行吗?那么:流式资源如何适应 RESTful 范式?
With a RESTful service you can create, read, update, and delete resources. This all works well when you're dealing with something like a database assets - but how does this translate to streaming data? (Or does it?) For instance, in the case of video, it seems silly to treat each frame as resource that I should query one at a time. Rather I would set up a socket connection and stream a series of frames. But does this break the RESTful paradigm? What if I want to be able to rewind or fast forward the stream? Is this possible within the RESTful paradigm? So: How do streaming resources fit within the RESTful paradigm?
作为实施问题，我正准备创建这样的流数据服务，并且我想确保我正在以最佳方式"进行操作.我确定这个问题以前已经解决了.有人能给我指点好的材料吗?
As a matter of implementation, I am getting ready to create such a streaming data service, and I want to make sure I'm doing it the "best way". I'm sure this problem's been solved before. Can someone point me to good material?
推荐答案
我没有找到真正关于 RESTful 流式传输 - 结果似乎主要是将流式传输委托给另一个服务(这不是一个糟糕的解决方案).所以我会尽力自己解决这个问题 - 请注意，流媒体不是我的领域，但我会尝试增加我的 2 美分.
I did not manage to find materials about truly RESTful streaming - it seems that results are mostly about delegating streaming to another service (which is not a bad solution). So I'll do my best to tackle it myself - note that streaming is not my domain, but I'll try to add my 2 cents.
在流媒体方面，我认为我们需要将问题分成两个独立的部分:
In the aspect of streaming, I think that we need to separate the problem into two independent parts:
- 访问媒体资源(元数据)
- 访问媒体/流本身(二进制数据)
1.) 访问媒体资源
这非常简单，可以以干净和 RESTful 的方式处理.例如，假设我们将有一个基于 XML 的 API，它允许我们访问流列表:
1.) Access to media resources
This is pretty straightforward and can be handled in a clean and RESTful way. As an example, let's say that we will have an XML-based API which allows us to access a list of streams:
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 单独访问框架.尽管这可能有效，但我同意您的看法，这不是一个可行的选择.
2.) Access to the medium/stream itself
This is the more problematic bit. You already pointed out one option in your question, and that is to allow access to frames individually via a RESTful API. Even though this might work, I agree with you that it's not a viable option.
我认为有一个选择:
- 通过专门的流媒体协议(例如 RTSP)将流媒体委托给专门的服务
- 利用 HTTP 中可用的选项
我相信前者是更有效的选择，尽管它需要专用流媒体服务(和/或硬件).它可能有点处于 RESTful 的边缘，但是请注意，我们的 API 在所有方面都是 RESTful，即使专用流服务不遵守统一接口 (GET/POST/PUT/DELETE)，我们的 API做.我们的 API 允许我们通过 GET/POST/PUT/DELETE 对资源及其元数据进行适当的控制，并且我们提供流媒体服务的链接(因此符合 REST 的连通性方面).
I believe the former to be the more efficient choice, although it requires a dedicated streaming service (and/or hardware). It might be a bit on the edge of what is considered RESTful, however note that our API is RESTful in all aspects and even though the dedicated streaming service does not adhere to the uniform interface (GET/POST/PUT/DELETE), our API does. Our API allows us proper control over resources and their meta data via GET/POST/PUT/DELETE, and we provide links to the streaming service (thus adhering with connectedness aspect of REST).
后一种选择 - 通过 HTTP 流式传输 - 可能不如上面那样有效，但绝对有可能.从技术上讲，这与允许通过 HTTP 访问任何形式的二进制内容没有什么不同.在这种情况下，我们的 API 将提供一个指向可通过 HTTP 访问的二进制资源的链接，并告知我们资源的大小:
The latter option - streaming via HTTP - might not be as efficient as the above, but it's definitely possible. Technically, it's not that different than allowing access to any form of binary content via HTTP. In this case our API would provide a link to the binary resource accessible via HTTP, and also advises us about the size of the resource:
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 渐进式下载.更简洁的替代方法是让客户端通过使用 HTTP 范围标题.为了获取 1MB 大文件的第二个 256KB 块，客户端请求将如下所示:
The client can access the resource via HTTP by using GET /media/1.3gp. One option is for the client to download the whole resource - HTTP progressive download. A cleaner alternative would be for the client to access the resource in chunks by utilizing HTTP Range headers. For fetching the second 256KB chunk of a file that is 1MB large, the client request would then look like this:
GET /media/1.3gp
...
Range: bytes=131072-262143
...
支持范围的服务器将响应 Content-范围头，后跟资源的部分表示:
A server which supports ranges would then respond with the Content-Range header, followed by the partial representation of the resource:
HTTP/1.1 206 Partial content
...
Content-Range: bytes 131072-262143/1048576
Content-Length: 1048576
...
请注意，我们的 API 已经告诉客户端文件的确切大小(以字节为单位)(1MB).在客户端不知道资源大小的情况下，它应该首先调用 HEAD/media/1.3gp 以确定大小，否则它会面临服务器响应 416 的风险请求的范围不满足.
Note that our API already told the client the exact size of the file in bytes (1MB). In a case where the client would not know the size of the resource, it should first call HEAD /media/1.3gp in order to determine the size, otherwise it's risking a server response with 416 Requested Range Not Satisfiable.
这篇关于流资源如何适应 RESTful 范式?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
