halforbit / api-client Goto Github PK

Today when an unexpected HTTP response code is encountered, ApiClient throws an ApiRequestException.

While this exception is rich with properties about the request and the response, if the server includes a text response body (often containing an error message), this is not easily surfaced. A work-around today is to catch the ApiRequestException and use its Response to get the text content, but we can probably do better.

Also, Response contains an ErrorMessage property that is only populated under some circumstances, and particularly not when an unexpected response code is encountered.

On an unexpected response code, let's try to interrogate the response body (if there is one) as text, and include that text in both the Message property of the exception as well as the ErrorMessage property.

curl has a concise and widely adopted format for describing web requests. Not only can a curl command be run at the command prompt, but Postman allows importing curl commands for a rich experience.

If we could furnish developers with a curl command that precisely describes their request, they could easily reproduce the request with the tool of their choice.

Let's add a property to the Response type for retrieving a curl command.

This feature might need to be opt-in, since if there is a request body we will need to retain it fully in memory in some form to be able to include its content in the curl command.

Today HTTP 429 is not included in the default list of retryable status codes, but it should be. So let's add it.

This article outlines the motivations for the move:
https://learn.microsoft.com/en-us/dotnet/architecture/microservices/implement-resilient-applications/use-httpclientfactory-to-implement-resilient-http-requests

Unfortunately, this is only supported in .NET Core 2.1+, so to retain backwards compatability, this will need to be switched off of target framework, with legacy .NET Framework 4.x continuing to use the existing pattern.