为媒体转换设计 REST 服务

Question

我当前的任务是设计一个 REST 服务，该服务可用于从一种媒体类型转换为另一种媒体类型（例如，从 video/x-msvieo 转换为 video/x-flv）。它不应该在浏览器中可用。 一般来说，我会让客户端发布媒体文件并返回一些 URL 以供进一步参考（如http://www.example.com/Media/12345）。

有趣的是——这就是问题出现的地方——转换过程可以用两种不同的方式来解释：

1) 转换后的媒体只是原始媒体的不同表示，因此要请求新格式的媒体，您只需 GET http://example.com/Media/12345，并在 Accept-header 中告诉服务您需要什么格式。例如，由于转换了大视频，该服务将响应 202 Accepted 直到转换完成。但是，如果转换因任何原因失败，会发生什么？

2) 由于转换需要很长时间，因此可以将进程表示为它自己的资源。在这种情况下，必须将某种形式的工作描述（可能是 xml）发布到 http://example.com/Media/12345，并且该服务将响应请求转换的新 URI（如 http://example.com/Media/12345/jobs/1）。但是这样的设计不会是完全非 REST-linke 的吗？

我目前拥有的是这样的：

1.) 将媒体文件发布到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 中的链接中选择以开始转换/通过 GETting 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 以了解当前发生的情况。

所以，非常感谢您阅读所有这些内容 :)
你觉得我的方法怎么样？你会做什么不同的事情？
我对这些东西很陌生，因此非常感谢任何建议。

亲切的问候：比尔

Answer 1

在第 4 步中，我会考虑使用 300 响应代码。您正在做与客户驱动的内容协商非常相似的事情。在这里查看它是如何完成的http://www.w3.org/TR/wd-xptr

您创建一个“作业”资源来表示新媒体文件的创建的想法是处理 RESTful 系统中长时间运行的操作的一种完全有效且非常常见的方法。

唯一的其他评论是，在第 5 步中，我最初担心使用 GET 来执行此操作，但经过仔细考虑，这似乎是合理的。这很好，因为最终转换的视频可以在相同的 URL 上提供。然后，客户所要做的就是意识到，如果他们请求视频并且得到 202，他们只需要稍等片刻即可重试。如果他们愿意，他们可以检查 ./status 资源以了解它是否完成。我想你只需要确保你是否已经在转换你返回另一个 202 但不要开始新的转换过程:-)

Answer 2

是的，重定向（大概）到http://example.com/Media/12345/jobs/1 听起来不太平静。听起来您正在尝试通过同步接口实现异步服务。难道你不能发布一个“转换请求”资源来启动返回会话的进程，即有点像：

Class ConversionRequest
{
 Guid sessionid
  Int status
…
}

然后使用 GET/sessionId 来检查转换的状态？根据我的经验，如果一个 Restful 界面开始变得复杂，这通常意味着该资源不适合手头的任务。

Answer 3

你的方法看起来不错。您可以在您的 URI 中对任何概念进行编码，其中显然包括 jobs 概念。这完全取决于您希望如何设计应用程序界面（资源）。

这是我攻击它的一种方法，它可能会给你一些想法。 （这取决于您的客户端和应用程序协议/接口：

• /媒体
  • GET - 媒体列表 + 状态等
  • POST - 添加媒体 + 返回位置： /media/{number}/jobs/{number}
• /媒体/{编号}
  • GET - 显示媒体状态（有效、进行中）、格式等。链接到默认/当前作业
• /media/{number}/jobs
  • GET - 工作列表
  • POST - 进行额外/特殊转换
• /media/{number}/formats/{name}
  • 获取 - 下载
  • PUT - 启动特定转换，重定向到作业。
• /media/{number}/jobs/{number} - 作业状态等。
  • GET - 状态等，
  • 删除 - 取消作业

请记住，PUT 和 DELETE 是幂等的，而 POST 不是。

您使用超媒体和链接的方式看起来不错。客户端应通过链接发现下一步或相关信息，而不是依赖 URI 结构等带外信息。