Как потоковые ресурсы вписываются в парадигму RESTful?

Question

С помощью службы RESTful вы можете создавать, читать, обновлять и удалять ресурсы. Все это хорошо работает, когда вы имеете дело с чем-то вроде активов базы данных, но как это переводит на потоковые данные? (Или это?) Например, в случае видео кажется глупым рассматривать каждый кадр как ресурс, который я должен запрашивать по одному. Скорее я бы установил соединение сокета и поток серии кадров. Но разве это нарушает парадигму RESTful? Что делать, если я хочу иметь возможность перематывать или перематывать поток вперед? Возможно ли это в рамках парадигмы RESTful? Итак: Как потоковые ресурсы вписываются в парадигму RESTful?

В целях реализации я собираюсь создать такую ​​услугу передачи потоковых данных, и я хочу убедиться, что я делаю это «лучший способ». Я уверен, что эта проблема была решена раньше. Может ли кто-нибудь указать мне хороший материал?

Answer 1

Мне не удалось найти материалы о действительно RESTful streaming - кажется, что результаты в основном касаются делегирования потоковой передачи на другую услугу (что не является плохим решением). Поэтому я сделаю все возможное, чтобы справиться с этим сам - обратите внимание, что потоковая передача - это не мой домен, но я постараюсь добавить свои 2 цента.

В аспекте потоковой передачи, я думаю, что нам нужно разделить задачу на две независимые части:

1. доступ к медиа-ресурсам (мета-данные)
2. доступа к среде/Ручей себя (двоичные данные)

1.) Доступ к медиа-ресурсам
Это довольно просто и может быть обработано в чистых и RESTful образом. В качестве примера, давайте предположим, что мы будем иметь 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. Хотя это может сработать, я согласен с вами в том, что это не жизнеспособный вариант.

Я думаю, что есть выбор должны быть заключено между:

1. делегирования потоковой к выделенной службе по протоколу специализированных течений (например, RTSP)
2. используя опции, доступные в 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 progressive download. Более простой альтернативой было бы для клиента получить доступ к ресурсу в кусках, используя HTTP Range headers. Для извлечения второго 256KB куска файла, который 1MB большой, запрос клиента будет выглядеть следующим образом:

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 
... 

Обратите внимание, что наш API уже сообщил клиенту точный размер файла в байтах (1 МБ). В случае, когда клиент не знает размер ресурса, он должен сначала позвонить HEAD /media/1.3gp, чтобы определить размер, иначе он рискует ответом сервера с 416 Requested Range Not Satisfiable.