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

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

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

92 голоса | спросил JnBrymn 28 Jpm1000000pmFri, 28 Jan 2011 20:40:32 +030011 2011, 20:40:32

1 ответ


0

Мне не удалось найти материалы о действительно потоковой передаче RESTful - похоже, что результаты в основном касаются делегирования потоковой передачи другому сервису (что является неплохим решением). Поэтому я сделаю все возможное, чтобы заняться этим самостоятельно - обратите внимание, что потоковая передача не является моей областью, но я постараюсь добавить свои 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.) Доступ к самой среде /потоку
Это более проблемный бит. Вы уже указали одну опцию в своем вопросе, а именно: предоставить индивидуальный доступ к фреймам через RESTful API. Хотя это может сработать, я согласен с вами, что это нереальный вариант.

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

  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 . Более чистой альтернативой было бы для клиента получить доступ к ресурсу частями, используя HTTP Заголовки диапазона . Для извлечения второго фрагмента размером 256 КБ из файла размером 1 МБ запрос клиента будет выглядеть следующим образом:

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

Сервер, который поддерживает диапазоны, будет затем отвечать Content- Заголовок диапазона , за которым следует частичное представление ресурса:

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.

ответил MicE 29 Jam1000000amSat, 29 Jan 2011 00:12:18 +030011 2011, 00:12:18

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132