स्ट्रीमिंग संसाधन रीस्टफुल प्रतिमान के भीतर कैसे फिट होते हैं?

Question

एक पुरानी सेवा के साथ आप संसाधन बना सकते हैं, पढ़ सकते हैं, अपडेट कर सकते हैं और हटा सकते हैं। यह सब ठीक काम करता है जब आप किसी डेटाबेस संपत्ति की तरह कुछ से निपट रहे हैं - लेकिन यह डेटा स्ट्रीमिंग में कैसे अनुवाद करता है? (या यह करता है?) उदाहरण के लिए, वीडियो के मामले में, प्रत्येक फ्रेम को संसाधन के रूप में मानने के लिए मूर्खतापूर्ण लगता है कि मुझे एक समय में एक से पूछना चाहिए। इसके बजाय मैं एक सॉकेट कनेक्शन स्थापित करता हूं और फ्रेम की एक श्रृंखला स्ट्रीम करता हूं। लेकिन क्या यह वास्तविक प्रतिमान तोड़ता है? क्या होगा अगर मैं स्ट्रीम को रिवाइंड या फास्ट फॉरवर्ड करने में सक्षम होना चाहता हूं? क्या यह यथार्थवादी प्रतिमान के भीतर संभव है? तो: स्ट्रीमिंग संसाधन रीस्टफुल प्रतिमान के भीतर कैसे फिट होते हैं?

कार्यान्वयन के मामले में, मैं ऐसी स्ट्रीमिंग डेटा सेवा बनाने के लिए तैयार हो रहा हूं, और मैं यह सुनिश्चित करना चाहता हूं कि मैं इसे "सर्वश्रेष्ठ तरीका" कर रहा हूं। मुझे यकीन है कि इस समस्या को हल किया गया है। क्या कोई मुझे अच्छी सामग्री के लिए इंगित कर सकता है?

Answer 1

मैं वास्तव में RESTful streaming के बारे में सामग्री खोजने में कामयाब नहीं रहा - ऐसा लगता है कि परिणाम अधिकतर किसी अन्य सेवा (जो एक खराब समाधान नहीं है) स्ट्रीमिंग के प्रतिनिधि हैं। इसलिए मैं इसे स्वयं से निपटने के लिए अपनी पूरी कोशिश करूंगा - ध्यान दें कि स्ट्रीमिंग मेरा डोमेन नहीं है, लेकिन मैं अपना 2 सेंट जोड़ने की कोशिश करूंगा।

स्ट्रीमिंग का पहलू में, मुझे लगता है कि हम दो स्वतंत्र भागों में समस्या को अलग करने की जरूरत है: (

1. मीडिया संसाधनों (मेटा डेटा) मध्यम करने के लिए
2. पहुँच/खुद स्ट्रीम करने के लिए उपयोग कर सकते बाइनरी डेटा)

1.) मीडिया संसाधनों तक पहुंच
यह बिल्कुल स्पष्ट है और एक साफ और RESTful तरह से संभाला जा सकता है। अलग-अलग धाराओं के

GET /media/ 

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

... और यह भी: उदाहरण के लिए, मान लीजिए कि हम जो हमें नदियों की एक सूची का उपयोग करने की अनुमति देता है एक XML- आधारित एपीआई होगा जाने

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 ।) माध्यम/स्ट्रीम स्वयं तक पहुंच
यह अधिक समस्याग्रस्त बिट है। आपने पहले से ही अपने प्रश्न में एक विकल्प बताया है, और यह एक विश्वसनीय API के माध्यम से अलग-अलग फ्रेम तक पहुंच की अनुमति देना है। भले ही यह काम कर सके, मैं आपसे सहमत हूं कि यह एक व्यवहार्य विकल्प नहीं है।

मुझे लगता है कि एक विकल्प है कि वहाँ के बीच किए जाने के लिए:

1. एक विशेष स्ट्रीमिंग प्रोटोकॉल के माध्यम से एक समर्पित सेवा के लिए स्ट्रीमिंग सौंपने (जैसे RTSP)
2. HTTP में उपलब्ध विकल्पों का उपयोग

मेरा मानना ​​है कि पूर्व अधिक कुशल विकल्प होने के लिए, हालांकि इसे समर्पित स्ट्रीमिंग सेवा (और/या हार्डवेयर) की आवश्यकता है। यह रीस्टफुल माना जाता है के किनारे पर थोड़ा सा हो सकता है, हालांकि ध्यान दें कि हमारा एपीआई सभी पहलुओं में रीस्टफुल है और भले ही समर्पित स्ट्रीमिंग सेवा एक समान इंटरफ़ेस (GET/POST/PUT/DELETE) का पालन नहीं करती है, हमारे API कर देता है। हमारा एपीआई हमें संसाधनों और उनके मेटा डेटा पर जीईटी/पोस्ट/पुट/डिलीट के माध्यम से उचित नियंत्रण की अनुमति देता है, और हम स्ट्रीमिंग सेवा के लिंक प्रदान करते हैं (इस प्रकार आरईएसटी के कनेक्टिविटी पहलू का पालन करते हैं)।

बाद वाला विकल्प - HTTP के माध्यम से स्ट्रीमिंग - उपर्युक्त के रूप में उतना कुशल नहीं हो सकता है, लेकिन यह निश्चित रूप से संभव है। तकनीकी रूप से, यह HTTP के माध्यम से बाइनरी सामग्री के किसी भी रूप तक पहुंच की अनुमति देने से अलग नहीं है। इस मामले में हमारी API 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> 

ग्राहक GET /media/1.3gp का उपयोग करके HTTP के माध्यम से संसाधन का उपयोग कर सकते हैं। एक विकल्प क्लाइंट के लिए संपूर्ण संसाधन डाउनलोड करने के लिए है - HTTP progressive download। HTTP Range headers का उपयोग कर क्लाइंट में संसाधनों तक पहुंचने के लिए क्लाइंट के लिए एक क्लीनर विकल्प होगा। एक फ़ाइल है कि 1 एमबी बड़ी है की दूसरी 256KB हिस्सा प्राप्त करने में कठिनाई के लिए, ग्राहक के अनुरोध तो इस प्रकार दिखाई देगा:

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

एक सर्वर जो पर्वतमाला तो Content-Range header साथ जवाब देगा का समर्थन करता है, संसाधन का आंशिक प्रतिनिधित्व के बाद :

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

ध्यान दें कि हमारे एपीआई पहले से ही ग्राहक बाइट्स में फ़ाइल (1MB) की सटीक आकार को बताया। ऐसे मामले में जहां ग्राहक संसाधन के आकार को नहीं जानता है, इसे पहले आकार निर्धारित करने के लिए HEAD /media/1.3gp पर कॉल करना चाहिए, अन्यथा यह 416 Requested Range Not Satisfiable के साथ सर्वर प्रतिक्रिया को जोखिम दे रहा है।