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

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

我在想类似的事情：

客户端使用转换配置目标类型、安全密钥、通知资源URL以返回请求id的形式发布/转换/请求资源。转换请求将添加到内部队列中，只要转换未启动，客户端就可以修改/删除。 转换启动后，服务器将删除/conversion/request/id 转换完成后，服务器在1资源中创建与上述相同的/conversion/result/id，然后对通知状态资源执行PUT操作，将其设置为就绪，并提供密钥，该密钥将通知客户端其请求已完成 当准备就绪时，客户机进行GET-on/conversion/result/id资源以获取转换后的文档 如果客户端因任何原因脱机，他可以尝试检索结果，如图4所示。如果文档尚未准备好，客户端只需等待发送通知即可。 然而

这是一种有效的方法吗？ 我是否应该忘记使用REST，而是应该考虑使用SOAP和阻塞调用，知道我更喜欢避免阻塞调用或JMS所有方法都有其优缺点，在我的上下文中，反对JMS的一个大缺点是，它需要为所有可能被拒绝的客户机设置队列注意：这就是为什么我还在这个问题中添加了SOAP和JMS标记 有没有关于如何改进方法的想法？在继续之前，我应该考虑哪些问题？ 提前感谢您的帮助

---

Michel在过去，我处理这个问题时使用了一个初始请求的POST，返回一个URI，其中包含最终文档的位置作为有效负载。然后，我用一个响应响应该位置的GET，直到处理完成。当处理完成后，我返回HTTP 200和内容。这使客户端的复杂性降至最低—这是一个简单的轮询，并且与HTTP语义保持一致

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

---

最后，此方法大大简化了错误处理。对于客户端正在执行的同一个GET，您始终可以返回500个错误。您不必为不同的错误情况指定不同的回调，这最终会成为API的一个真正难点。

我只会使用这样一个资源：

POST/conversion/{meta}{attachment}->201创建的{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"}
    ]
}

---

状态更改和百分比更改可以使用SSE、轮询或WebSocket将数据推回或触发更新。Ofc。这只是草稿。

谢谢你的回答。我的错误是：我想的是通知，而不是真正的回调。服务器尝试以最佳方式修改状态，如果无法访问客户端，则服务器无需执行任何特殊操作。我希望避免投票，正如我所写的，JMS可能因为不好的原因而不被接受，但我希望能够提供一个可行的尽可能智能的替代方案。我根据这个答案修改了我的帖子。