Je n'ai pas réussi à trouver des matériaux sur vraiment Reposante streaming - il semble que les résultats sont généralement à propos de la délégation de la diffusion sur un autre service (ce qui n'est pas une mauvaise solution). Donc je vais faire de mon mieux pour lutter contre moi-même - à noter que le streaming n'est pas mon domaine, mais je vais essayer d'ajouter mes 2 cents.
Dans l'aspect de la diffusion, je pense que nous avons besoin de séparer le problème en deux parties indépendantes:
- l'accès à des ressources multimédias (méta-données)
- l'accès au médium/flux lui-même (données binaires)
1.) L'accès aux ressources pour les médias
C'est assez simple et peut être manipulé dans un endroit propre et Reposant. Comme un exemple, disons que nous allons avoir une API basées sur XML, ce qui nous permet d'accéder à une liste de cours d'eau:
GET /media/
<?xml version="1.0" encoding="UTF-8" ?>
<media-list uri="/media">
<media uri="/media/1" />
<media uri="/media/2" />
...
</media-list>
...et aussi pour les flux individuels:
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.) L'accès au médium/flux lui-même
C'est la plus problématique bits. Vous l'a déjà souligné une option dans votre question, et que c'est pour permettre l'accès à des images individuellement par l'intermédiaire d'une API RESTful. Même si cela peut fonctionner, je suis d'accord avec vous que ce n'est pas une option viable.
Je pense qu'il y a un choix à faire entre:
- déléguer en streaming à un service dédié via un spécialisé en streaming de protocole (par exemple, RTSP)
- en utilisant les options disponibles dans HTTP
Je crois que les anciens pour être le plus efficace, même si elle nécessite un dédié service de streaming (et/ou le matériel). Il pourrait être un peu sur le bord de ce qui est considéré comme Reposant, cependant, noter que notre API RESTful dans tous les aspects, et même si l'dédié un service de streaming de ne pas adhérer à l'interface uniforme (GET/POST/PUT/DELETE), notre API. Notre API nous permet un bon contrôle sur les ressources et de leurs méta-données via GET/POST/PUT/DELETE, et nous fournissons des liens vers le service de streaming (donc en adhérant à la connectivité aspect de REPOS).
La dernière option - streaming via HTTP - pourrait ne pas être aussi efficace que le précédent, mais il est certainement possible. Techniquement, il n'est pas si différent que de permettre l'accès à toute forme de contenu binaire via HTTP. Dans ce cas, notre API serait de fournir un lien vers la ressource binaire accessible via HTTP, et nous conseille également sur la taille de la ressource:
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>
Le client peut accéder à la ressource via HTTP en utilisant GET /media/1.3gp. Une option est pour le client de télécharger l'ensemble de la ressource - HTTP téléchargement progressif. Une alternative plus propre serait pour le client d'accéder à la ressource en morceaux en utilisant HTTP Éventail des en-têtes. Pour récupérer le deuxième 256KB morceau d'un fichier de 1 mo à grande, à la demande du client ressemblerait alors à ceci:
GET /media/1.3gp
...
Range: bytes=131072-262143
...
Un serveur qui prend en charge plages seraient ensuite réagir avec le Contenu de Gamme en-tête, suivi par la représentation partielle de la ressource:
HTTP/1.1 206 Partial content
...
Content-Range: bytes 131072-262143/1048576
Content-Length: 1048576
...
Notez que notre API déjà dit au client la taille exacte du fichier en octets (1 MO). Dans le cas où le client ne serait pas savoir la taille de la ressource, il faut d'abord appeler HEAD /media/1.3gp afin de déterminer la taille, sinon, c'est risquer une réponse du serveur avec 416 Requested Range Not Satisfiable.
