Like this:

[Fact]
public async Task Get_UserWithId1_ReturnsDynamicWithUsernameBretAndOkStatusCode()
{
   var client = new RestClient("https://jsonplaceholder.typicode.com", new Config()
                .SetJsonSerializerSettings(new JsonSerializerSettings { ContractResolver = new CamelCasePropertyNamesContractResolver() }));

   await client
      .Resource("users/1").Get()
      .Verify(userIsBret => userIsBret.username == "Bret")
      .Verify(httpResponseMessageIsOk => httpResponseMessageIsOk.HttpResponseMessage.StatusCode == HttpStatusCode.OK);
}

View live example

Head over to my post on Code Maze, and your be testing REST API’s using C# in no time at all.

Since starting the project in Jan 2015 one of the most asked for features has been full static support (you have always been able to cast responses via duck typing). Inspired by libraries written in dynamic languages like JavaScript and Python – the idea behind RestClient was to reduce the fiction and ceremony when working with Rest API’s, and later on HTTP in general.

I’ve always wanted to add static typing to be more inline with what is expected from a C# library, but wanted to do it in such way that the original concept remained, and that all code is backwards compatible. I’ve now spent the time required to change the package, and this is the result:

DalSoft Rest Client https://github.com/DalSoft/DalSoft.RestClient

Continue reading »

Before 3.3.1 if you wanted to control serialization you would have to decorate your model with attributes, for example if your REST API used snake case naming convention:

public class User
{
  [JsonProperty("phone_number")]
  public string PhoneNumber { get; set; }
}

As of 3.3.1 you can provide JsonSerializerSettings to the config – this saves you having to add the attributes to properties individually, which will make your code cleaner. For example if your REST API used snake case naming convention:

// When directly creating a RestClient instance
dynamic restClient = new RestClient("https://dalsoft.co.uk", new Config()
	.SetJsonSerializerSettings(new JsonSerializerSettings { ContractResolver =  new DefaultContractResolver { NamingStrategy = new SnakeCaseNamingStrategy() } }));

// When using IHttpClientFactory
 services
	.AddRestClient(Name, "https://dalsoft.co.uk")
	.SetJsonSerializerSettings(new JsonSerializerSettings { ContractResolver =  new DefaultContractResolver { NamingStrategy = new SnakeCaseNamingStrategy() } });

Now the SnakeCaseNamingStrategy ContractResolver is used by default when deserializing responses from your REST API.

To find out more about DalSoft.RestClient including the new JsonSerializerSettings head over to https://restclient.dalsoft.io

I recently needed to use Twitter’s API along with it’s OAuth 1.0 implementation in .NET Core. As part of this work I created a DalSoft.RestClient Handler, and released it as a full SDK.

Continue reading »

Prior to .NET Core 2.1 anyone who has tried to use HttpClient at scale (maybe from a microservice) may have run into the dreaded socket exhaustion issue.

Socket exhaustion happens because HttpClient is designed to be instantiated once and re-used throughout the life of an application, if you make HTTP calls in a server application for every request you will run out of sockets (because sockets get left in TIME_WAIT state for 240 seconds by default).

Using IHttpClientFactory can improve performance by 43%!

Continue reading »