我有一个用户个人资料的API资源(由移动应用程序使用)。用户可以通过PUT提交数据并获得响应。如果数据不正确,我会返回422和错误说明,否则返回200.
但是有一种数据状态在域逻辑方面是正确的,但需要管理员手动干预。在这种情况下,请求成功,但我需要向用户显示一个消息,他的情况非常特殊,并将由管理员进行调查。
问题是:如何以REST的方式执行此操作? 202状态?或者只是200和纯文本消息?或创建另一个资源,如个人资料/验证,并在提交新数据后立即使用它?
答案 0 :(得分:1)
我认为202适合这里。
来自RFC [202 Accepted]: The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status code from an asynchronous operation such as this.
不幸的是,RFC for PUT
没有提到请求的异步处理。我认为202是这种情况的有效解决方案(但这只是我的观点)。在他们的一天结束时,最好与您的API消费者交谈,看看他们的想法。
答案 1 :(得分:0)
是的。 HTTP 202非常适合这种情况。您可以在RFC 7231
中阅读202(已接受)状态代码表示请求已为
接受处理,但处理尚未完成 该请求可能会或可能不会最终被采取行动,因为它可能会 处理实际发生时不允许。没有 HTTP中的工具,用于从异步中重新发送状态代码 操作202回复是故意不置可否的。 其目的是 允许服务器接受某个其他进程的请求 (也许是一个每天只运行一次的面向批处理的进程) ,无需用户代理与服务器的连接,直到流程完成为止。 发送此响应应该描述请求的当前 状态并指向(或嵌入)可提供的状态监视器 估计何时满足请求的用户。
强调我的。
因此,您应该在标题中发送一个202状态的响应,以及一条消息,说明通知用户该请求有效并正在处理的原因以及他不应该重复该请求。
但是有一种数据状态在域逻辑方面是正确的,但需要管理员手动干预。
这对应于
最终可能会或可能不会对请求采取行动 在实际处理时不允许。