How do streaming resources fit into the RESTful paradigm?

Question

With the RESTful service, you can create, read, update, and delete resources. All this works well when you are dealing with something like database assets, but how does this translate to streaming data? (Or is it?) For example, in the case of video, it seems silly to consider each frame as a resource, which I must request one at a time. Rather, I would establish a socket connection and a stream of a series of frames. But does this violate the RESTful paradigm? What if I want to be able to rewind or rewind the stream forward? Is this possible within the framework of the RESTful paradigm? So: How do streaming resources fit into the RESTful paradigm?

For implementation purposes, I am ready to create such a streaming service, and I want to make sure that I am doing this "the best way." I am sure this problem has been resolved before. Can someone point me to some good stuff?

Answer 1

I was not able to find materials about really RESTful streaming - it seems that the results mainly relate to delegating streaming to another service (which is not a bad solution). Therefore, I will do my best to deal with this myself - note that streaming is not my domain, but I will try to add my 2 cents.

In the aspect of streaming, I think we need to divide the problem into two independent parts:

• access to media resources (metadata)
• access to the tool / stream itself (binary data)

1.) Access to media resources
It is quite simple and can be handled in a clean and RESTful way. As an example, suppose we have an XML-based API that allows us to access a list of threads:

GET /media/ <?xml version="1.0" encoding="UTF-8" ?> <media-list uri="/media"> <media uri="/media/1" /> <media uri="/media/2" /> ... </media-list> 

... as well as individual threads:

 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.) Access to the tool / stream itself
This is a more problematic bit. You have already indicated one of the options in your question, and this means that frames are accessed individually through the RESTful API. While this may work, I agree with you that this is not a viable option.

I think there is a choice between:

• delegating streaming to a dedicated service through a dedicated streaming protocol (e.g. RTSP)
• using options available in HTTP

I believe the former was a more efficient choice, although it requires a dedicated streaming service (and / or hardware). It may be a little on the verge of being considered RESTful, however, please note that our RESTful API in all aspects and even though the specialized streaming service does not adhere to a single interface (GET / POST / PUT / DELETE), our API does. Our API allows us to properly control resources and their metadata through GET / POST / PUT / DELETE, and we provide links to streaming services (thus adhering to the REST connectivity aspect).

The final option, streaming over HTTP , may not be as efficient as described above, but it is definitely possible. Technically, this is not what differs from allowing access to any form of binary content via HTTP. In this case, our API will provide a link to a binary resource accessible via HTTP, and also tell 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> 

The client can access the resource via HTTP using GET /media/1.3gp . One option is for the client to download the entire resource - HTTP progressive download . A cleaner alternative would be for the client to access the resource in chunks using HTTP range headers . To receive a second block of 256 KB in size, a file of 1 MB in size, the client request will look like this:

 GET /media/1.3gp ... Range: bytes=131072-262143 ... 

Then a server that supports ranges responds with a Content-Range header , followed by a partial representation of the resource:

 HTTP/1.1 206 Partial content ... Content-Range: bytes 131072-262143/1048576 Content-Length: 1048576 ... 

Please note that our API has already informed the client the exact file size in bytes (1 MB). In the case when the client does not know the size of the resource, it must first call HEAD /media/1.3gp to determine the size, otherwise it risks a server response using 416 Requested Range Not Satisfiable .