Skip to content

Commit d523197

Browse files
committed
Fixes per editoring
1 parent f3ecbb7 commit d523197

File tree

1 file changed

+5
-5
lines changed

1 file changed

+5
-5
lines changed

articles/azure-maps/creator-long-running-operation-v2.md

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,9 @@
11
---
2-
title: Azure Maps Long-Running Operation API V2
2+
title: Azure Maps long-running operation API V2
33
description: Learn about long-running asynchronous V2 background processing in Azure Maps
44
author: anastasia-ms
55
ms.author: v-stharr
6-
ms.date: 05/12/2020
6+
ms.date: 05/18/2021
77
ms.topic: conceptual
88
ms.service: azure-maps
99
services: azure-maps
@@ -15,7 +15,7 @@ ms.custom: mvc
1515

1616
Some APIs in Azure Maps use an [Asynchronous Request-Reply pattern](/azure/architecture/patterns/async-request-reply). This pattern allows Azure Maps to provide highly available and responsive services. This article explains Azure Map's specific implementation of long-running asynchronous background processing.
1717

18-
## Submitting a request
18+
## Submit a request
1919

2020
A client application starts a long-running operation through a synchronous call to an HTTP API. Typically, this call is in the form of an HTTP POST request. When an asynchronous workload is successfully created, the API will return an HTTP `202` status code, indicating that the request has been accepted. This response contains a `Location` header pointing to an endpoint that the client can poll to check the status of the long-running operation.
2121

@@ -29,7 +29,7 @@ Operation-Location: https://atlas.microsoft.com/service/operations/{operationId}
2929

3030
If the call doesn't pass validation, the API will instead return an HTTP `400` response for a Bad Request. The response body will provide the client more information on why the request was invalid.
3131

32-
### Monitoring the operation status
32+
### Monitor the operation status
3333

3434
The location endpoint provided in the accepted response headers can be polled to check the status of the long-running operation. The response body from operation status request will always contain the `status` and the `created` properties. The `status` property shows the current state of the long-running operation. Possible states include `"NotStarted"`, `"Running"`, `"Succeeded"`, and `"Failed"`. The `created` property shows the time the initial request was made to start the long-running operation. When the state is either `"NotStarted"` or `"Running"`, a `Retry-After` header will also be provided with the response. The `Retry-After` header, measured in seconds, can be used to determine when the next polling call to the operation status API should be made.
3535

@@ -45,7 +45,7 @@ Retry-After: 30
4545
}
4646
```
4747

48-
## Handling operation completion
48+
## Handle operation completion
4949

5050
Upon completing the long-running operation, the status of the response will either be `"Succeeded"` or `"Failed"`. All responses will return an HTTP 200 OK code. When a new resource has been created from a long-running operation, the response will also contain a `Resource-Location` header that points to metadata about the resource. Upon a failure, the response will have an `error` property in the body. The error data adheres to the OData error specification.
5151

0 commit comments

Comments
 (0)