When you want to consume your API App from your application our Visual Studio tooling does all the magic (aka generation) for you. Because of Swagger, we can generate the code of the API App client with two clicks. All you have to do is point the API App Client SDK to your API App (or the Swagger file) and we’ll do the generation of the code for you. You can find more details about this feature and how to use it at Consume an API app in Azure App Service from a .NET client
Once you have your code though, you might want to customize a couple of things, like e.g. the HttpClient timeout or set a RetryPolicy.
Setting the HttpClient properties
The HttpClient is publicly accessible from the code and you can customize it. Increasing the timeout or setting custom headers to be send to your API App, could be as simple as:
Setting a retry policy to handle transient errors
When we’re trying to consume an API App or in general, a web application, there are cases where transient errors will happen and a simple retry will make the call go through. There are various reasons why transient errors manifest but the key here is handling them and retrying before failing a call.
The API App client has built in support for retry logic and all we have to do is provide the “RetryPolicy” we want to use. In our code this will look like:
In this case we’re using the default retry policy which detects “50x” errors and retries in the case, but there might be other cases were we want to retry.
Creating a custom retry policy
We can create a custom retry policy and pass this to the API App client. First we have to implement the “ITransientErrorDetectionStrategy” interface.
PS. Keep in mind that this is just an example the above Exceptions might not be representative or thorough.
All we do in this case is check if the exception is of a type we think is a transient error and return true. This will let the RetryPolicy know that it has to retry based on the “RetryStrategy” we have set for this API App client. Using the custom retry policy will look like this:
In the “IsTransient” method of the “ITransientErrorDetectionStrategy” interface you can do whatever kind of check you want but just keep in mind that this has to be fairly fast as you’re blocking the continuation as long as you don’t return something.
A retry strategy is generally a wise thing to do but just keep in mind that it has to be within reasonable limits and intervals. Overdoing it will hurt the performance of the application and not necessarily improve the reliability.