在REST API中，如果我有一个资源，创建可能需要相当长的时间，我可以返回状态代码为202的临时资源 . 然后，客户端可以轮询此临时资源，直到创建实际资源并在完成时重定向到它（带有303状态代码） . 像http://restcookbook.com/Resources/asynchroneous-operations/中描述的东西 .
在OData中是否有任何标准化的方法来创建这样的资源？
在REST API中，如果我有一个资源，创建可能需要相当长的时间，我可以返回状态代码为202的临时资源 . 然后，客户端可以轮询此临时资源，直到创建实际资源并在完成时重定向到它（带有303状态代码） . 像http://restcookbook.com/Resources/asynchroneous-operations/中描述的东西 .
在OData中是否有任何标准化的方法来创建这样的资源？
1 回答
OData V4 specification中（简要地）提到了异步请求 . 这可能值得阅读细节，但简而言之：
客户端发出包含
Prefer: respond-async标头的请求 . 然后，服务器可以按照您的描述使用HTTP 202响应进行响应 . 此响应包含LocationHeaders ，指向'status monitor resource' .当客户端向状态监视器资源发送请求时，有3个主要响应：
HTTP 202：操作尚未完成 .HTTP 200：操作完成 . 此响应还必须包含AsyncResult标头，该标头保存操作的状态代码（例如，成功为200，错误为5xx等） . 此响应的主体包含操作的结果 .HTTP 404：该操作不存在 .
操作已取消 .
操作可能已存在，但客户端在请求状态之前等待的时间太长（也可能是
HTTP 410 (Gone)） .我不知道任何实现此行为的框架，因此您可能需要自己编程 .