Мені не вдалося знайти матеріали про справді RESTful потокове передавання - схоже, результати в основному стосуються делегування потокового потоку в інший сервіс (що не є поганим рішенням). Тому я зроблю все можливе, щоб вирішити це самостійно - зауважте, що потокове передача - це не мій домен, але я спробую додати свої 2 центи.
В аспекті потокової передачі я думаю, що нам потрібно розділити проблему на дві незалежні частини:
- доступ до медіаресурсів (метаданих)
- доступ до самого середовища / потоку (двійкові дані)
1.) Доступ до медіа-ресурсів
Це досить просто і з ними можна обробляти чистий і ВІДПОВІДНИЙ спосіб. Наприклад, скажімо, що у нас буде API на основі XML, який дозволяє нам отримувати доступ до списку потоків:
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.) Доступ до самого середовища / потоку
Це більш проблемний біт. Ви вже вказали на один із варіантів свого питання, а це надати доступ до кадрів індивідуально через API RESTful. Незважаючи на те, що це може спрацювати, я згоден з вами, що це непридатний варіант.
Я думаю, що вибір може бути зроблений між:
- делегування потокової передачі в спеціалізовану службу через спеціалізований протокол потокового передавання (наприклад, RTSP)
- використовуючи параметри, доступні в HTTP
Я вважаю, що колишній вибір є більш ефективним, хоча він вимагає спеціального потокового сервісу (та / або апаратного забезпечення). Це може бути трохи на межі того, що вважається RESTful, однак зауважте, що наш API є RESTful у всіх аспектах, і навіть якщо спеціалізований сервіс потокової передачі не дотримується єдиного інтерфейсу (GET / POST / PUT / DELETE), наш API робить. Наш API дозволяє нам належним чином контролювати ресурси та їх метадані через GET / POST / PUT / DELETE, і ми надаємо посилання на потокову службу (таким чином, дотримуючись аспекту зв'язку REST).
Останній варіант - потокове передавання через 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>
Клієнт може отримати доступ до ресурсу через HTTP за допомогою GET /media/1.3gp. Один варіант - клієнт може завантажити весь ресурс - прогресивне завантаження HTTP . Більш чіткою альтернативою було б клієнт отримати доступ до ресурсу шматками, використовуючи заголовки діапазону HTTP . Для отримання другого фрагмента 256 КБ файлу, розміром якого є 1 Мб, запит клієнта буде виглядати приблизно так:
GET /media/1.3gp
...
Range: bytes=131072-262143
...
Потім сервер, що підтримує діапазони, відповість заголовком Content-Range з подальшим частковим поданням ресурсу:
HTTP/1.1 206 Partial content
...
Content-Range: bytes 131072-262143/1048576
Content-Length: 1048576
...
Зауважте, що наш API вже повідомив клієнту точний розмір файлу в байтах (1 МБ). У випадку, коли клієнт не знає розмір ресурсу, спочатку слід зателефонувати HEAD /media/1.3gp, щоб визначити розмір, інакше ризикує відповідь сервера 416 Requested Range Not Satisfiable.