Akış kaynakları RESTful paradigmasına nasıl uyuyor?

Question 1

RESTful hizmeti ile kaynakları oluşturabilir, okuyabilir, güncelleyebilir ve silebilirsiniz. Bu, veritabanı varlıkları gibi bir şeyle uğraşırken iyi çalışır - ancak bu, veri akışına nasıl dönüşür? (Ya da öyle mi?) Örneğin, video söz konusu olduğunda, her kareyi teker teker sorgulamam gereken kaynak olarak ele almak aptalca görünüyor. Bunun yerine bir soket bağlantısı kurar ve bir dizi çerçeve yayınlardım. Ama bu RESTful paradigmasını bozar mı? Akışı geri veya hızlı ileri sarabilmek istiyorsam ne olur? RESTful paradigması içinde bu mümkün mü? Öyleyse: Akış kaynakları RESTful paradigmasına nasıl uyuyor?

Uygulama meselesi olarak, böyle bir veri akışı hizmeti oluşturmaya hazırlanıyorum ve bunu "en iyi şekilde" yaptığımdan emin olmak istiyorum. Eminim bu problem daha önce çözülmüştür. Birisi beni iyi bir malzemeye yönlendirebilir mi?

Question 2

Gerçekten RESTful akışla ilgili materyal bulmayı başaramadım - sonuçların çoğunlukla başka bir hizmete akış yetkisi vermekle ilgili olduğu görülüyor (bu kötü bir çözüm değil). Bu yüzden kendim halletmek için elimden gelenin en iyisini yapacağım - akışın benim alanım olmadığını unutmayın, ancak 2 sentimi eklemeye çalışacağım.

Akış açısından, sorunu iki bağımsız bölüme ayırmamız gerektiğini düşünüyorum:

medya kaynaklarına erişim (meta veri)
ortama / akışın kendisine erişim (ikili veriler)

1.) Medya kaynaklarına erişim
Bu oldukça basittir ve temiz ve DİNLENMELİ bir şekilde ele alınabilir. Örnek olarak, bir akış listesine erişmemizi sağlayan XML tabanlı bir API'ye sahip olacağımızı varsayalım:

GET /media/

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

... ve ayrıca tek tek akışlara:

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.) Ortama / akışın kendisine erişim
Bu daha sorunlu olan bittir. Sorunuzda zaten bir seçeneğe işaret ettiniz ve bu, çerçevelere bir RESTful API aracılığıyla tek tek erişime izin vermek. Bu işe yarasa bile, bunun uygun bir seçenek olmadığı konusunda sizinle aynı fikirdeyim.

Aşağıdakiler arasında yapılacak bir seçim olduğunu düşünüyorum:

Özel bir akış protokolü (örneğin RTSP) aracılığıyla akışı özel bir hizmete devretme
HTTP'de bulunan seçenekleri kullanmak

Özel bir akış hizmeti (ve / veya donanım) gerektirmesine rağmen, eskisinin daha verimli bir seçim olduğuna inanıyorum . RESTful olarak kabul edilen şeyin biraz sınırında olabilir, ancak API'mizin her açıdan RESTful olduğunu ve özel akış hizmetinin tek tip arayüze (GET / POST / PUT / DELETE), API'mize uymamasına rağmen unutmayın. yapar. API'miz, GET / POST / PUT / DELETE aracılığıyla kaynaklar ve meta verileri üzerinde uygun kontrol sağlamamıza izin verir ve akış hizmetine bağlantılar (böylece REST'in bağlılık yönüne bağlı kalarak) sağlarız.

İkinci seçenek - HTTP yoluyla akış - yukarıdaki kadar verimli olmayabilir, ancak kesinlikle mümkündür. Teknik olarak, HTTP aracılığıyla herhangi bir ikili içerik biçimine erişime izin vermekten çok da farklı değil. Bu durumda API'miz, HTTP aracılığıyla erişilebilen ikili kaynağa bir bağlantı sağlar ve ayrıca kaynağın boyutu hakkında bize bilgi verir:

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>

İstemci, kullanarak HTTP aracılığıyla kaynağa erişebilir GET /media/1.3gp. Bir seçenek, istemcinin tüm kaynağı indirmesidir - HTTP aşamalı indirme . İstemcinin HTTP Aralığı başlıklarını kullanarak kaynağa yığınlar halinde erişmesi daha temiz bir alternatif olacaktır . 1MB büyüklüğündeki bir dosyanın ikinci 256 KB'lik parçasını getirmek için, istemci isteği şu şekilde görünür:

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

Aralıkları destekleyen bir sunucu daha sonra Content-Range başlığıyla yanıt verir ve ardından kaynağın kısmi gösterimi gelir:

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

API'mızın müşteriye dosyanın bayt cinsinden tam boyutunu (1MB) zaten söylediğini unutmayın. İstemcinin kaynağın boyutunu bilmediği bir durumda, boyutu HEAD /media/1.3gpbelirlemek için önce araması gerekir , aksi takdirde bir sunucu yanıtını riske atar 416 Requested Range Not Satisfiable.