Merge pull request #175783 from jakrams/user/jakras/rest

Add information about REST call delay

Author: PRMerger-2

articles/remote-rendering/how-tos/frontend-apis.md

@@ -15,6 +15,7 @@ In this section, we will describe how to use the API for authentication and sess
 > [!CAUTION]
 > The functions described in this chapter issue REST calls on the server internally. As for all REST calls, sending these commands too frequently will cause the server to throttle and return failure eventually. The value of the `SessionGeneralContext.HttpResponseCode` member in this case is 429 ("too many requests"). As a rule of thumb, there should be a delay of **5-10 seconds between subsequent calls**.
 
+Some functions also return information when it is save to retry. For example `RenderingSessionPropertiesResult.MinimumRetryDelay` specifies how many seconds to wait before attempting another check. When available, using such a returned value is best, as it allows you to do checks as often as possible, without getting throttled.
 
 ## SessionConfiguration
 

articles/remote-rendering/resources/troubleshoot.md

@@ -32,9 +32,9 @@ If you are working on a laptop with two GPUs, it is possible that the GPU you ar
 
 ## Retrieve session/conversion status fails
 
-Sending REST API commands too frequently will cause the server to throttle and return failure eventually. The http status code in the throttling case is 429 ("too many requests"). As a rule of thumb, there should be a delay of **5-10 seconds between subsequent calls**.
+Sending REST API commands too frequently will cause the server to throttle and return failure eventually. The HTTP status code in the throttling case is 429 ("too many requests"). As a rule of thumb, there should be a delay of **5-10 seconds between subsequent calls**.
 
-Note this limit not only affects the REST API calls when called directly but also their C#/C++ counterparts, such as `Session.GetPropertiesAsync`, `Session.RenewAsync`, or `Frontend.GetAssetConversionStatusAsync`.
+Note this limit not only affects the REST API calls when called directly but also their C#/C++ counterparts, such as `Session.GetPropertiesAsync`, `Session.RenewAsync`, or `Frontend.GetAssetConversionStatusAsync`. Some functions also return information when it is save to retry. For example `RenderingSessionPropertiesResult.MinimumRetryDelay` specifies how many seconds to wait before attempting another check. When available, using such a returned value is best, as it allows you to do checks as often as possible, without getting throttled.
 
 If you experience server-side throttling, change the code to do the calls less frequently. The server will reset the throttling state every minute, so it is safe to rerun the code after a minute.
 

articles/remote-rendering/samples/powershell-example-scripts.md

@@ -21,7 +21,7 @@ The [ARR samples repository](https://github.com/Azure/azure-remote-rendering) co
 > There is also a [UI-based tool called ARRT](azure-remote-rendering-asset-tool.md) to interact with the service, which is a convenient alternative to using scripts. ![ARRT](./media/azure-remote-rendering-asset-tool.png "ARRT screenshot")
 
 > [!CAUTION]
-> Calling REST API functions too frequently will cause the server to throttle and return failure eventually. The http failure code id in this case is 429 ("too many requests"). As a rule of thumb, there should be a delay of **5-10 seconds between subsequent calls**.
+> Calling REST API functions too frequently will cause the server to throttle and return failure eventually. The HTTP failure code id in this case is 429 ("too many requests"). As a rule of thumb, there should be a delay of **5-10 seconds between subsequent calls**.
 
 ## Prerequisites