In order for a call to the following endpoint:
to be treated as an asynchronous request the "Prefer: respond-async" header needs to be added.
Looking at the documentation here:
and here:
https://hosted.datascopeapi.reuters.com/RestApi/v1/Jobs/$metadata
can I confirm that:
1) The monitor url (that is returned in the Location header of the "ScheduleExtractNow" response if the call takes longer than 30 seconds) also needs the "Prefer: respond-async" header if I want it to return a 202 Accepted after 30 seconds for long running requests?
2) None of the following endpoints support the asynchronous behaviour and therefore do no need the "Prefer: respond-async" header:
https://hosted.datascopeapi.reuters.com/RestApi/v1/Authentication/RequestToken https://hosted.datascopeapi.reuters.com/RestApi/v1/Extractions/Schedules('{0}')/LastExtraction https://hosted.datascopeapi.reuters.com/RestApi/v1/Extractions/ReportExtractions('{0}')/Files https://hosted.datascopeapi.reuters.com/RestApi/v1/Extractions/ExtractedFiles('{0}')/$value
?
1) Monitor calls do not need the Prefer: respond-async header.
2) These are preferences (including respond-async) which means that the API may choose not to respect the header. The examples you mentioned in #2 that do not need the respond-async preference will simply ignore the prefer-async header. The preference is not needed, but won't cause any problems. However, only set the prefer-async header if your client side code is ready to accept a 202 since we do reserve the right to support asynchronous behavior on methods and would not consider it a breaking change.
@Troy Dalldorf Regarding 1) - does this mean the Monitor url will return a response after a specified time with a 202 Accepted status code or it will never respond with a 202 Accepted and it will eventually respond with a 200 OK and the result of the extraction?
@mdoberschuetz, the monitor URL will return either: