मैंने वास्तव में Restful स्ट्रीमिंग के बारे में सामग्री खोजने का प्रबंधन नहीं किया - ऐसा लगता है कि परिणाम ज्यादातर स्ट्रीमिंग को किसी अन्य सेवा (जो एक बुरा समाधान नहीं है) को सौंपने के बारे में हैं। तो मैं इसे खुद से निपटने की पूरी कोशिश करूंगा - ध्यान दें कि स्ट्रीमिंग मेरा डोमेन नहीं है, लेकिन मैं अपने 2 सेंट जोड़ने की कोशिश करूंगा।
स्ट्रीमिंग के पहलू में, मुझे लगता है कि हमें समस्या को दो स्वतंत्र भागों में अलग करने की आवश्यकता है:
- मीडिया संसाधनों तक पहुंच (मेटा डेटा)
- माध्यम / स्ट्रीम तक पहुंच (बाइनरी डेटा)
1.) मीडिया संसाधनों तक पहुंच
यह बहुत सरल है और इसे एक स्वच्छ और उत्साहपूर्ण तरीके से नियंत्रित किया जा सकता है। एक उदाहरण के रूप में, मान लें कि हमारे पास 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 के माध्यम से व्यक्तिगत रूप से फ़्रेम तक पहुंच की अनुमति देना। हालांकि यह काम कर सकता है, मैं आपसे सहमत हूं कि यह एक व्यवहार्य विकल्प नहीं है।
मुझे लगता है कि इसके बीच एक विकल्प है:
- एक विशेष स्ट्रीमिंग प्रोटोकॉल (जैसे RTSP) के माध्यम से एक समर्पित सेवा के लिए स्ट्रीमिंग का प्रतिनिधित्व करना
- HTTP में उपलब्ध विकल्पों का उपयोग करना
मेरा मानना है कि पूर्व को अधिक कुशल विकल्प माना जाता है, हालांकि इसके लिए एक समर्पित स्ट्रीमिंग सेवा (और / या हार्डवेयर) की आवश्यकता होती है। यह Restful माना जाता है के किनारे पर थोड़ा सा हो सकता है, हालांकि ध्यान दें कि हमारा API सभी पहलुओं में RESTful है और भले ही समर्पित स्ट्रीमिंग सेवा एक समान इंटरफ़ेस (GET / POST / PUT / DELETE) का पालन नहीं करती है, हमारा API कर देता है। हमारा एपीआई हमें GET / POST / PUT / DELETE के माध्यम से संसाधनों और उनके मेटा डेटा पर उचित नियंत्रण की अनुमति देता है, और हम स्ट्रीमिंग सेवा (इस प्रकार REST के कनेक्टिविटी पहलू के साथ पालन) के लिए लिंक प्रदान करते हैं।
बाद वाला विकल्प - HTTP के माध्यम से स्ट्रीमिंग - ऊपर के रूप में कुशल नहीं हो सकता है, लेकिन यह निश्चित रूप से संभव है। तकनीकी रूप से, यह HTTP के माध्यम से द्विआधारी सामग्री के किसी भी रूप तक पहुंच की अनुमति देने से अलग नहीं है। इस स्थिति में हमारा एपीआई 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>
क्लाइंट HTTP का उपयोग करके संसाधन तक पहुंच सकता है GET /media/1.3gp। एक विकल्प क्लाइंट के लिए संपूर्ण संसाधन डाउनलोड करने के लिए है - HTTP प्रगतिशील डाउनलोड । क्लाइंट के लिए HTTP रेंज हेडर का उपयोग करके क्लीनर में संसाधन का उपयोग करने के लिए एक क्लीनर विकल्प होगा । किसी फ़ाइल का दूसरा 256KB हिस्सा जो 1MB बड़ा है, को लाने के लिए, क्लाइंट अनुरोध फिर इस तरह दिखेगा:
GET /media/1.3gp
...
Range: bytes=131072-262143
...
एक सर्वर जो पर्वतमाला का समर्थन करता है, तब सामग्री-रेंज हेडर के साथ प्रतिक्रिया करेगा , इसके बाद संसाधन का आंशिक प्रतिनिधित्व होगा:
HTTP/1.1 206 Partial content
...
Content-Range: bytes 131072-262143/1048576
Content-Length: 1048576
...
ध्यान दें कि हमारे एपीआई ने ग्राहक को पहले ही बाइट्स (1 एमबी) में फ़ाइल का सटीक आकार बता दिया था। ऐसे मामले में जहां ग्राहक को संसाधन के आकार का पता नहीं होगा, आकार HEAD /media/1.3gpको निर्धारित करने के लिए पहले इसे कॉल करना चाहिए , अन्यथा इसके साथ एक सर्वर प्रतिक्रिया का जोखिम है 416 Requested Range Not Satisfiable।