Skip to main content

Using Flurl to easily build URLs and make testable HttpClient calls in .NET

FlurlI posted about using Refit along with ASP.NET Core 2.1's HttpClientFactory earlier this week. Several times when exploring this space (both on Twitter, googling around, and in my own blog comments) I come upon Flurl as in, "Fluent URL."

Not only is that a killer name for an open source project, Flurl is very active, very complete, and very interesting. By the way, take a look at the https://flurl.io/ site for a great example of a good home page for a well-run open source library. Clear, crisp, unambiguous, with links on how to Get It, Learn It, and Contribute. Not to mention extensive docs. Kudos!

Flurl is a modern, fluent, asynchronous, testable, portable, buzzword-laden URL builder and HTTP client library for .NET.

You had me at buzzword-laden! Flurl embraces the .NET Standard and works on .NET Framework, .NET Core, Xamarin, and UWP - so, everywhere.

To use just the Url Builder by installing Flurl. For the kitchen sink (recommended) you'll install Flurl.Http. In fact, Todd Menier was kind enough to share what a Flurl implementation of my SimpleCastClient would look like! Just to refresh you, my podcast site uses the SimpleCast podcast hosting API as its back-end.

My super basic typed implementation that "has a" HttpClient looks like this. To be clear this sample is WITHOUT FLURL.

public class SimpleCastClient

{

    private HttpClient _client;

    private ILogger<SimpleCastClient> _logger;

    private readonly string _apiKey;

 

    public SimpleCastClient(HttpClient client, ILogger<SimpleCastClient> logger, IConfiguration config)

    {

        _client = client;

        _client.BaseAddress = new Uri($"https://api.simplecast.com"); //Could also be set in Startup.cs

        _logger = logger;

        _apiKey = config["SimpleCastAPIKey"]; 

    }

 

    public async Task<List<Show>> GetShows()

    {

        try

        {

            var episodesUrl = new Uri($"/v1/podcasts/shownum/episodes.json?api_key={_apiKey}", UriKind.Relative);

            _logger.LogWarning($"HttpClient: Loading {episodesUrl}");

            var res = await _client.GetAsync(episodesUrl);

            res.EnsureSuccessStatusCode();

            return await res.Content.ReadAsAsync<List<Show>>();

        }

        catch (HttpRequestException ex)

        {

            _logger.LogError($"An error occurred connecting to SimpleCast API {ex.ToString()}");

            throw;

        }

    }

}

Let's explore Tim's expression of the same client using the Flurl library!

Not we set up a client in Startup.cs, use the same configuration, and also put in some nice aspect-oriented events for logging the befores and afters. This is VERY nice and you'll note it pulls my cluttered logging code right out of the client!

// Do this in Startup. All calls to SimpleCast will use the same HttpClient instance.

FlurlHttp.ConfigureClient(Configuration["SimpleCastServiceUri"], cli => cli

    .Configure(settings =>

    {

        // keeps logging & error handling out of SimpleCastClient

        settings.BeforeCall = call => logger.LogWarning($"Calling {call.Request.RequestUri}");

        settings.OnError = call => logger.LogError($"Call to SimpleCast failed: {call.Exception}");

    })

    // adds default headers to send with every call

    .WithHeaders(new

    {

        Accept = "application/json",

        User_Agent = "MyCustomUserAgent" // Flurl will convert that underscore to a hyphen

    }));

Again, this set up code lives in Startup.cs and is a one-time thing. The Headers, User Agent all are dealt with once there and in a one-line chained "fluent" manner.

Here's the new SimpleCastClient with Flurl.

using Flurl;

using Flurl.Http;


public class SimpleCastClient

{

    // look ma, no client!

    private readonly string _baseUrl;

    private readonly string _apiKey;

 

    public SimpleCastClient(IConfiguration config)

    {

        _baseUrl = config["SimpleCastServiceUri"]; 

        _apiKey = config["SimpleCastAPIKey"]; 

    }

 

    public Task<List<Show>> GetShows()

    {

        return _baseUrl

            .AppendPathSegment("v1/podcasts/shownum/episodes.json")

            .SetQueryParam("api_key", _apiKey)

            .GetJsonAsync<List<Show>>();

    }

}

See in GetShows() how we're also using the Url Builder fluent extensions in the Flurl library. See that _baseUrl is actually a string? We all know that we're supposed to use System.Uri but it's such a hassle. Flurl adds extension methods to strings so that you can seamlessly transition from the strings (that we all use) representations of Urls/Uris and build up a Query String, and in this case, a GET that returns JSON.

Very clean!

Flurl also prides itself on making HttpClient testing easier as well. Here's a more sophisticated example of a library from their site:

// Flurl will use 1 HttpClient instance per host

var person = await "https://api.com"

    .AppendPathSegment("person")

    .SetQueryParams(new { a = 1, b = 2 })

    .WithOAuthBearerToken("my_oauth_token")

    .PostJsonAsync(new

    {

        first_name = "Claire",

        last_name = "Underwood"

    })

    .ReceiveJson<Person>();

This example is doing a post with an anonymous object that will automatically turn into JSON when it hits the wire. It also receives JSON as the response. Even the query params are created with a C# POCO (Plain Old CLR Object) and turned into name=value strings automatically.

Here's a test Flurl-style!

// fake & record all http calls in the test subject

using (var httpTest = new HttpTest()) {

    // arrange

    httpTest.RespondWith(200, "OK");

    // act

    await sut.CreatePersonAsync();

    // assert

    httpTest.ShouldHaveCalled("https://api.com/*")

        .WithVerb(HttpMethod.Post)

        .WithContentType("application/json");

}

Flurl.Http includes a set of features to easily fake and record HTTP activity. You can make a whole series of assertions about your APIs:

httpTest.ShouldHaveCalled("http://some-api.com/*")

    .WithVerb(HttpMethd.Post)

    .WithContentType("application/json")

    .WithRequestBody("{\"a\":*,\"b\":*}") // supports wildcards

    .Times(1)

All in all, it's an impressive set of tools that I hope you explore and consider for your toolbox! There's a ton of great open source like this with .NET Core and I'm thrilled to do a small part to spread the word. You should to!

Sponsor: Check out dotMemory Unit, a free unit testing framework for fighting all kinds of memory issues in your code. Extend your unit testing with the functionality of a memory profiler.


© 2018 Scott Hanselman. All rights reserved.
     


from Scott Hanselman's Blog http://feeds.hanselman.com/~/554305488/0/scotthanselman~Using-Flurl-to-easily-build-URLs-and-make-testable-HttpClient-calls-in-NET.aspx
Labels:

Comments

Post a Comment

Popular posts from this blog

Rail Fence Cipher Program in C and C++[Encryption & Decryption]

Here you will get rail fence cipher program in C and C++ for encryption and decryption. It is a kind of transposition cipher which is also known as zigzag cipher. Below is an example. Here Key = 3. For encryption we write the message diagonally in zigzag form in a matrix having total rows = key and total columns = message length. Then read the matrix row wise horizontally to get encrypted message. Rail Fence Cipher Program in C #include<stdio.h> #include<string.h> void encryptMsg(char msg[], int key){ int msgLen = strlen(msg), i, j, k = -1, row = 0, col = 0; char railMatrix[key][msgLen]; for(i = 0; i < key; ++i) for(j = 0; j < msgLen; ++j) railMatrix[i][j] = '\n'; for(i = 0; i < msgLen; ++i){ railMatrix[row][col++] = msg[i]; if(row == 0 || row == key-1) k= k * (-1); row = row + k; } printf("\nEncrypted Message: "); for(i = 0; i < key; ++i) f...
3 comments
Read more

Data Encryption Standard (DES) Algorithm

Data Encryption Standard is a symmetric-key algorithm for the encrypting the data. It comes under block cipher algorithm which follows Feistel structure. Here is the block diagram of Data Encryption Standard. Fig1: DES Algorithm Block Diagram [Image Source: Cryptography and Network Security Principles and Practices 4 th Ed by William Stallings] Explanation for above diagram: Each character of plain text converted into binary format. Every time we take 64 bits from that and give as input to DES algorithm, then it processed through 16 rounds and then converted to cipher text. Initial Permutation: 64 bit plain text goes under initial permutation and then given to round 1. Since initial permutation step receiving 64 bits, it contains an 1×64 matrix which contains numbers from 1 to 64 but in shuffled order. After that, we arrange our original 64 bit text in the order mentioned in that matrix. [You can see the matrix in below code] After initial permutation, 64 bit text passed throug...
Post a Comment
Read more

Experimental: Reducing the size of .NET Core applications with Mono's Linker

The .NET team has built a linker to reduce the size of .NET Core applications. It is built on top of the excellent and battle-tested mono linker . The Xamarin tools also use this linker so it makes sense to try it out and perhaps use it everywhere! "In trivial cases, the linker can reduce the size of applications by 50%. The size wins may be more favorable or more moderate for larger applications. The linker removes code in your application and dependent libraries that are not reached by any code paths. It is effectively an application-specific dead code analysis ." - Using the .NET IL Linker I recently updated a 15 year old .NET 1.1 application to cross-platform .NET Core 2.0 so I thought I'd try this experimental linker on it and see the results. The linker is a tool one can use to only ship the minimal possible IL code and metadata that a set of programs might require to run as opposed to the full libraries. It is used by the various Xamarin products to extract...
Post a Comment
Read more