Разработка сервиса REST для конвертации медиа - PullRequest
Новая
       10

Разработка сервиса REST для конвертации медиа

4 голосов
/ 25 марта 2011

Моя текущая задача - разработать REST-сервис, который можно использовать для преобразования из одного типа мультимедиа в другой (например, из видео / x-msvieo в видео / x-flv). Его нельзя использовать в браузере. Как правило, я позволяю клиентам POST медиа-файлы и возвращаю им некоторые URL для дальнейшего использования (например, http://www.example.com/Media/12345).

Интересно, - и вот где возникают вопросы - что процесс преобразования можно интерпретировать двумя различными способами:

1) Преобразованный носитель - это просто другое представление исходного, поэтому для запроса носителя в новом формате вы можете просто получить GET http://example.com/Media/12345, и указать службе в заголовке Accept, какой формат вы используете. необходимость. После конвертации, например, большого видео, служба ответит 202 «Принято» до завершения конвертации. Но что должно произойти, если преобразование не удалось по какой-либо причине?

2) Поскольку преобразование занимает очень много времени, можно представить процесс как его собственный ресурс. В этом случае нужно будет отправить POST некоторую форму описания задания (вероятно, xml) в http://example.com/Media/12345, и служба ответит новым URI для запрошенного преобразования (например, http://example.com/Media/12345/jobs/1). Но не будет такого рода дизайн будет совсем не REST-линке?

То, что у меня сейчас есть, это:

1.) POST медиафайл на http://example.com/Media
2.) Ответ: 201 Создано / Местоположение: http://example.com/Media/12345
3.) ПОЛУЧИТЬ http://example.com/Media/12345
4.) Ответ: 200 Ok и xml вот так: 

<media id="123457">
    <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://example.com/Media/12345/video/x-flv">video/x-flv</link>
    <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://example.com/Media/12345/video/mpeg">video/mpeg</link>
</media>

Ссылки в xml отправляют вас к целям конверсии, доступным для этого носителя.

5.) Выберите из ссылок в xml, чтобы начать преобразование / получить результат, набрав http://example.com/Media/12345/video/mpeg
6.) Ответ: 202 Принято / Местоположение: http://example.com/Media/12345/video/mpeg/Status
7.) Повторяйте шаг 5, пока преобразование не будет выполнено, или посмотрите на http://example.com/Media/12345/video/mpeg/Status, чтобы увидеть, что происходит в настоящее время.

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

С уважением: Билл

Ответы [ 3 ]

2 голосов
/ 25 марта 2011

На шаге 4 я хотел бы рассмотреть возможность использования кода ответа 300. Вы делаете что-то очень похожее на согласование контента на основе клиента. Посмотрите, как это делается здесь http://www.w3.org/TR/wd-xptr

Ваша идея создать ресурс "job" для представления создания нового мультимедийного файла - это совершенно правильный и очень распространенный подход к обработке длительных операций в системах RESTful.

Единственный другой комментарий заключается в том, что на шаге 5 я изначально был обеспокоен использованием GET для этого, но подумав об этом немного больше, это кажется разумным. Это хорошо, потому что финальное конвертированное видео можно сделать доступным по тому же URL. Тогда все, что нужно сделать клиенту, это знать, что если он запрашивает видео и получает 202, ему просто нужно немного подождать, прежде чем повторить попытку. Если они хотят, они могут проверить ресурс ./status, чтобы узнать, сделано ли это. Я полагаю, вам просто нужно убедиться, что вы уже находитесь в процессе конвертации, вы вернули еще 202, но не начинаете новый процесс конвертации :-)

1 голос
/ 25 марта 2011

Да, перенаправление (предположительно) на http://example.com/Media/12345/jobs/1 не выглядит очень успокоительным. Похоже, вы пытаетесь реализовать асинхронный сервис через синхронный интерфейс. Не могли бы вы ПОСТАВИТЬ ресурс «запроса на конверсию», чтобы запустить процесс, который возвращает сеанс, то есть немного похоже на: 

Class ConversionRequest
{
 Guid sessionid
  Int status
…
}

Затем используйте GET / sessionId, чтобы проверить состояние конвертации? По моему опыту, если спокойный интерфейс начинает казаться сложным, это обычно означает, что ресурс не подходит для поставленной задачи.

0 голосов
/ 26 марта 2011

Вы подходите, кажется, хорошо. Вы можете закодировать любую концепцию в ваших URI, которая, очевидно, включает в себя концепцию jobs . Все зависит от того, как вы хотите разработать интерфейс приложения (ресурсы).

Вот один из способов напасть на него, и он может дать вам некоторые идеи. (Это зависит от ваших клиентов и протокола / интерфейса приложения :

  • / СМИ
    • GET - Список медиа + статус и т. Д.
    • POST - Добавить медиа + возвращает Расположение: / медиа / {число} / вакансии / {число}
  • / носитель / {число}
    • GET - Показывает статус мультимедиа (Действительный, Выполняется), форматы и т. Д. Ссылки на стандартные / текущие задания
  • / СМИ / {число} / работа
    • GET - Список работ
    • POST - делать дополнительное / специальное преобразование
  • / СМИ / {число} / форматы / {имя}
    • GET - Скачать
    • PUT - начать конкретное преобразование, перенаправить на задание.
  • / media / {number} / jobs / {number} - Статус работы и т. Д.
    • GET - Статус и т. Д.,
    • УДАЛИТЬ - Отменить задание

Помните, что PUT и DELETE являются идемпотентными, а POST нет.

Способ использования гипермедиа и ссылок выглядит хорошо. Клиент должен обнаруживать следующий шаг или связанную информацию через ссылки и не полагаться на внешнюю информацию, такую ​​как структура URI.

...