Designing a REST service for converting multimedia

Question

My current task is to create a REST service that can be used to convert from one type of media to another (for example, from video / x-msvieo to video / x-flv). It cannot be used for browser. Typically, I allow POST clients to download media files and return them a URL for future use (for example, http://www.example.com/Media/12345 ).

The interesting thing is that when questions arise, the conversion process can be interpreted in two different ways:

1) The converted media is just another representation of the source, so to request the media in a new format, you can simply GET http://example.com/Media/12345 , and tell the service in the Accept-header that you need the format. Since when converting, for example, a large video, the service will respond with 202 Accepted until the conversion is complete. But what should happen if the conversion is not for any reason?

2) Since the conversion takes such a long time, one could imagine the process as its own resource. In this case, you would need to POST to describe some form of job description (possibly xml) at http://example.com/Media/12345 , and the service will respond with new URIs for the requested conversion (for example, http://example.com / Media / 12345 / jobs / 1 ). But wouldn't such a design be anything but a REST-linke?

I currently have:

1.) Download the media file at http://example.com/Media
2.) Answer: 201 Created / Location: http://example.com/Media/12345
3.) GET http://example.com/Media/12345
4.) Answer: 200 Ok and 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> 

The links in xml send you the conversion goals available for this medium.

5.) Select from the links in xml to start the conversion / get the result using GETting http://example.com/Media/12345/video/mpeg
6.) Answer: 202 Accepted / Location: http://example.com/Media/12345/video/mpeg/Status
7.) Repeat step 5 until the conversion is complete or look at http://example.com/Media/12345/video/mpeg/Status to see what is currently happening.

So thank you very much for reading all this stuff :)
What do you think of my approach? What would you do differently? I am completely new to this, so any suggestions are highly appreciated.

Regards: Bill

Answer 1

In step 4, I would consider using a 300 response code. You are doing something very similar to client-based content negotiation. See how this is done here http://www.w3.org/TR/wd-xptr

Your idea of ​​creating a “job” resource to represent the creation of a new media file is a perfectly correct and very general approach to handling lengthy operations in RESTful systems.

The only other comment is that in step 5 I was initially worried about using GET for this, but thinking about it a little more seems reasonable. This is nice because the final converted video can be made available at the same address. Then all the client needs to do is to know that if they request a video and get 202, they just need to wait a bit before retrying. If they want to, they can check the resource. / status to see if this is done. I think you just need to make sure that you are already going to convert you, return another 202, but do not start a new conversion process :-)

Answer 2

Yes, redirecting (presumably) to http://example.com/Media/12345/jobs/1 doesn’t sound very calm. It looks like you are trying to implement an asynchronous service through a synchronous interface. Could you POST the conversion request resource to start a process that returns a session, that is, a bit like:

 Class ConversionRequest { Guid sessionid Int status … } 

Then use GET / sessionId to check conversion status? In my experience, if a soothing interface starts to feel complicated, it usually means that the resource is not suitable for the task.

Answer 3

You are approaching, it seems beautiful. You can code any concept in your URIs, which obviously includes the concept of jobs. It all depends on how you want to create your application interface (resources).

Here is one way that I would attack him, and this may give you some ideas. (It depends on your clients and application protocol / interface :

• /MASS MEDIA
  • GET - List of media + status, etc.
  • POST - Add media + returns Location: / media / {number} / jobs / {number}
• / carrier / {number}
  • GET - Shows the status of the media file (Valid, Running), formats, etc. Default Job Links / Current Jobs
• / Media / {number} / work
  • GET - Task List
  • POST - additional / special conversion
• / Media / {number} / formats / {name}
  • GET - Download
  • PUT - Start a specific conversion, redirect to the task.
• / media / {number} / jobs / {number} - job status, etc.
  • GET - Status, etc.,
  • DELETE - Cancel the task

Remember that PUT and DELETE are idempotent and POST not.

The way you use hypermedia and links looks good. The client should discover the next step or related information through links and not rely on out-of-band information such as a URI structure.