Post by fish on Aug 17, 2018 8:32:00 GMT
Chapter “8.2. Asynchronous operations” in the specification states the following about Task Monitor for completed asynchronous operations:
Once the operation has completed, the Task Monitor shall return a the appropriate status code ( OK 200 for most operations, Created 201 for POST to create a resource) and include the headers and response body of the initial operation, as if it had completed synchronously. If the initial operation resulted in an error, the body of the response shall contain an Error Response.
But this text only talks about the body of the response in case of error/failure scenario of the original asynchronous operation. HTTP status code to use in case of failure in the asynchronous operation is not explicitly described as far as I can see. Should I assume that the Task Monitor shall have a response with status codes, e.g. in series 400 or 500, corresponding to the failure reason of the original asynchronous operation? This seems to be a good approach as the Task Monitor would then be a clean “mirror” of the finished original asynchronous operation. But possible disadvantage with this approach could be that the client cannot distinguish between failure in the original asynchronous operation and failure in the Task Monitor request itself, at least based on the HTTP status code. (But maybe possible from error message in the Task Monitor response body.) What is the intended usage of the Task Monitor response status code in this case? Would you consider to clarify this in the specification?
Once the operation has completed, the Task Monitor shall return a the appropriate status code ( OK 200 for most operations, Created 201 for POST to create a resource) and include the headers and response body of the initial operation, as if it had completed synchronously. If the initial operation resulted in an error, the body of the response shall contain an Error Response.
But this text only talks about the body of the response in case of error/failure scenario of the original asynchronous operation. HTTP status code to use in case of failure in the asynchronous operation is not explicitly described as far as I can see. Should I assume that the Task Monitor shall have a response with status codes, e.g. in series 400 or 500, corresponding to the failure reason of the original asynchronous operation? This seems to be a good approach as the Task Monitor would then be a clean “mirror” of the finished original asynchronous operation. But possible disadvantage with this approach could be that the client cannot distinguish between failure in the original asynchronous operation and failure in the Task Monitor request itself, at least based on the HTTP status code. (But maybe possible from error message in the Task Monitor response body.) What is the intended usage of the Task Monitor response status code in this case? Would you consider to clarify this in the specification?
