我们正在实现一个REST API,它将启动多个长时间运行的后端任务。我一直在阅读《RESTful Web Services Cookbook》,它的建议是返回HTTP 202 / Accepted,并使用Content-Location标头指向正在处理的任务(例如http://www.example.org/orders/tasks/1234),并让客户端轮询此URI以获取长时间运行任务的更新。
这样做的想法是立即将REST API发布到队列中,然后由后台工作角色从队列中接收消息并启动多个后端任务,也使用队列。我看到这种方法存在的问题是如何为任务分配唯一ID,并随后让客户端通过向Content-Location URI发出GET请求来请求任务的状态。
如果REST API立即发布到队列,则可以生成GUID并将其附加为添加到队列的消息的属性,但是获取请求状态变得麻烦。
另一个选择是让REST API立即向数据库添加条目(假设是订单,具有新的订单ID),具有初始状态,然后随后将消息放入队列以启动后台任务,然后随后更新该数据库记录。 API将在Content-Location标头的URI中返回此新订单ID,供客户端在检查任务状态时使用。
先添加数据库条目,然后再添加消息到队列似乎很奇怪,但仅将请求添加到队列会使跟踪进度变得困难。
推荐的方法是什么?
非常感谢您的见解。
这样做的想法是立即将REST API发布到队列中,然后由后台工作角色从队列中接收消息并启动多个后端任务,也使用队列。我看到这种方法存在的问题是如何为任务分配唯一ID,并随后让客户端通过向Content-Location URI发出GET请求来请求任务的状态。
如果REST API立即发布到队列,则可以生成GUID并将其附加为添加到队列的消息的属性,但是获取请求状态变得麻烦。
另一个选择是让REST API立即向数据库添加条目(假设是订单,具有新的订单ID),具有初始状态,然后随后将消息放入队列以启动后台任务,然后随后更新该数据库记录。 API将在Content-Location标头的URI中返回此新订单ID,供客户端在检查任务状态时使用。
先添加数据库条目,然后再添加消息到队列似乎很奇怪,但仅将请求添加到队列会使跟踪进度变得困难。
推荐的方法是什么?
非常感谢您的见解。