Question

什么是适当的REST兼容方法，允许客户端调用RESTful服务以将（大）文档转换为目标格式？

我在考虑类似的事情：

客户端在POST资源上生成/conversion/request，其中包含将返回请求ID的转换配置（目标类型，安全密钥，格式为http://host_to_be_notified/notification/status/id的通知资源URL）。转换请求将添加到内部队列，只要转换未启动，客户端就可以修改/删除转换请求。
转化开始后，服务器

/conversion/request/id

转换完成后，服务器创建/conversion/result/id（与1中相同的id）资源，然后对通知状态资源执行PUT（将其设置为“ready”并提供密钥），这将通知客户完成其请求
准备好后，客户端在GET资源上创建/conversion/result/id以获取转换后的文档
如果客户因任何原因离线，他可以尝试检索4中的结果。如果文档没有准备好，客户只需要等待发送通知。

...然而

这是一种有效的方法吗？
我应该忘记使用REST，我是否应该考虑使用SOAP（并且有阻塞调用，知道我更愿意避免阻塞调用）或JMS（所有方法都有它们的优点/缺点，以及对JMS的一个重大缺点在我的上下文中，它需要为所有可能被拒绝的客户端设置队列）（注意：这就是为什么我还在这个问题上添加了“SOAP”和“JMS”标签）
如何改进方法以及在进一步探讨之前我应该考虑哪些问题？

提前感谢您的帮助！

米歇尔

Answer 1

过去我用初始请求的POST处理了这个问题，返回一个URI，其中最终doc的位置作为有效负载。然后，我在该位置回复GETS并发出HTTP 202响应，直到处理完成。处理完成后，我返回HTTP 200和内容。这最大限度地降低了客户端的复杂性（这是一个简单的轮询），并且与HTTP语义保持一致。

如果你真的想要实现一个回调方法，你可以，但它增加了很大的复杂性，我无法想象它会简化另一端的事情。轮询过程使他们可以更自由地实现try / wait-loop或将位置转储到表/队列以进行批处理。

最后，此方法显着简化了错误处理。您始终可以在客户端所进行的同一GET上返回500错误。您不必为不同的错误条件指定不同的回调（这最终成为API的真正痛点）。

Answer 2

我只会使用这样的资源：

<generator object lem at 0xdeadbeef> - ＆gt; POST /conversion/ {meta} {attachment}

之后，转换表示将在不同的状态中包含类似这些链接的属性：

入队

201 created {links: [{rel: "self", href: "/conversion/1"}]}

处理

{
    id: 1,
    status: "enqueued",
    links: [
        {rel: "self", href: "/conversion/1"},
        {rel: "remove", href: "/conversion/1"},
        {rel: "status-change", href: "/conversion/1/status/events"}
    ]
}

完整

{
    id: 1,
    status: "processing",
    percent: 99,
    links: [
        {rel: "self", href: "/conversion/1"},
        {rel: "status-change", href: "/conversion/1/status/events"},
        {rel: "percent-change", href: "/conversion/1/percent/events"}
    ]
}

{ id: 1, status: "complete", links: [ {rel: "self", href: "/conversion/1"}, {rel: "result", href: "/conversion/1/file"} ] }和status-change可以使用SSE，轮询或websockets来推送数据或触发更新。 OFC。这只是一个草案。

什么是文件转换服务的有效REST方法？

2 个答案: