我们正在使用JSON-API标准来开发我们的API，我们遇到的问题似乎没有遵循标准的明显解决方案。
Usecase如下：
有一个API端点，允许您订阅邮件列表。 一种可能的流程是用户添加为PENDING 表示用户将收到并选择接收电子邮件进行确认。
如果是这种情况，我们希望向前端回复消息 可以显示给用户，敦促他点击链接。
从我的观点来看，这不是一个真正的错误状态，更多的是后续元信息。所以这意味着将它放在错误消息中在概念上是不合逻辑的。此外，如果我们确实将它放在错误消息中，前端必须将其与“真正的错误”区分开来。某种程度上（状态代码具有如此低的分辨率，碰撞似乎是不可避免的）。
但是我们不返回资源，因此我们无法将其作为元信息添加到资源中。所以现在我不知道在哪里提供这些信息。
一种可能的解决方案是定义某种“响应”。资源并把它放在那里，但这似乎只是一堆蠕虫。
有什么想法吗？投入将受到极大重视
答案 0 :(得分：1)
如果调用的结果是用户已添加到邮件列表，请返回200 OK。如果通话结果是用户必须通过电子邮件选择加入，请返回gist。返回包含相关信息的202的响应对象。
来自规范：
202（已接受）状态代码表示请求已被执行 接受处理，但处理尚未完成。 该请求最终可能会或可能不会被执行 在实际处理时不允许。没有 HTTP中的工具，用于从异步中重新发送状态代码 操作
202回复是故意不置可否的。其目的是为了 允许服务器接受某个其他进程的请求（也许是 没有的批处理过程，每天只运行一次 要求用户代理与服务器的连接保持不变 直到过程完成。与此一起发送的表示 响应应该描述请求的当前状态并指向 （或嵌入）可以为用户提供的状态监视器 估计何时满足请求。