为什么在实现Async api w /轮询时,是否有“Get Status”步骤?

2022-09-24 22:19:15标签apirestasynchronousarchitecture
提问

通常,我看到以下的轮询: 发送一个请求并返回一个惟一的ID。 在请求已经完成的情况下,一个“状态”端点对客户端进行了投票。 发送一个请求来获取响应。 为什么步骤(2)和(3)不能组合? 如果响应还没有准备好,它将返回没有响应的回复和一些状态。 如果它已经准备好,它将返回响应。 为什么(2)和(3)通常是单独的步骤? 是否准备好是布尔真/假,响应可以是任何东西。通常,调用“准备就绪”,然后编写逻辑来处理真实和错误,而不是编写逻辑来获取响应,以确定响应是否没有准备好,或者是您需要的数据类型。 在这种情况下,逻辑是所有的客户端,但如果您将它们合并,您需要在客户机和服务器上都有逻辑(两者都说它还没有准备好,并处理实际的响应)。你可以这样做,但保持它分开就能保持整洁。 这种模式通常由HTTP 202状态代码定义,这是HTTP协议启动异步请求的机制。 我们可以考虑到202的响应,这表明已经创建了一个工作。如果工作执行时,可能(或可能)产生一些业务实体。假定客户端接收到202的客户最终对未来存在的业务实体(或可能不会存在)感兴趣,但现在肯定不存在,因此得到202的响应。 因此,返回一个职位地位的一个简单的原因是,现在的工作状态存在,我们更喜欢确定现在存在的东西,而不是未来存在的事情。接收请求的端点甚至不能为(未来)业务实体生成ID。 另一个原因是地位规范。状态端点返回一个可以描述工作可以存在的无限潜在状态的自定义工作状态。这些工作状态超出了HTTP状态代码的范围。w3定义的标准代码已经有了精确的定义;而且没有一个标准的HTTP状态代码意味着“继续投票”。 原因在于,他们从REST的角度来说是不同的资源。 让我们用一个例子来检验一下: 如果你想要下订单,首先你必须提交一个订单请求 然后在后台有一个长时间的异步过程,检查支付有效性是否在库存中可用。 如果一切顺利,那么将会有一个订单集与一些子元素(如订单项目运输地址等)。 从休息的角度来看: 有一个邮政/订单端点来下订单 有一个GET / order_request / { id }端点来检索顺序请求 有一个GET / order / { id }端点来检索顺序细节 当订单和所有相关的子资源被创建时,那么2。端点通常以303的方式响应,参见其他状态代码,要求消费者重定向获取/订单/ { id }。

回答

回答

回答

▼版权说明

相关文章也很精彩
推荐内容
更多标签
相关热门
全站排行
随便看看

错说cuoshuo.com——程序员的报错记录

部分内容根据CC版权协议转载,如果您希望取消转载请发送邮件到cuoshuo8@163.com

辽ICP备19011660号-5