Blog 2

As a .NET developer, I’ve spent countless hours working with external APIs. It’s a crucial part of modern software development, but let’s be honest – it can be a real pain sometimes.

We’ve all been there, wrestling with HttpClient, writing repetitive code, and hoping we didn’t miss a parameter or header somewhere.

That’s why I want to introduce you to Refit, a library that’s been a game-changer for me.

Imagine turning your API into a live interface – sounds too good to be true, right? But that’s exactly what Refit does. It handles all the HTTP heavy lifting, letting you focus on what matters: your application logic.

In this article, I’ll explain how Refit can transform the way you work with APIs in your .NET projects.

What is Refit?

Refit is a type-safe REST library for .NET. It allows you to define your API as an interface, which Refit then implements for you. This approach reduces boilerplate code and makes your API calls more readable and maintainable.

You describe your API endpoints using method signatures and attributes, and Refit takes care of the rest.

Let me break down why I find Refit so powerful:

• Automatic serialization and deserialization: You won’t have to convert your objects to JSON and back. Refit handles all of that for you.
• Strongly-typed API definitions: Refit helps you catch errors early. If you mistype a parameter or use the wrong data type, you’ll know at compile time, not when your app crashes in production.
• Support for various HTTP methods: GET, POST, PUT, PATCH, DELETE – Refit has you covered.
• Request/response manipulations: You can add custom headers or handle specific content types in a straightforward way.

But what I appreciate most about Refit is how it promotes clean, readable code. Your API calls become self-documenting. Anyone reading your code can quickly understand what each method does without diving into implementation details.

Setting Up and Using Refit in Your Project

Let’s set up Refit and see it in action using the JSONPlaceholder API. We’ll implement a full CRUD interface and demonstrate its usage in a Minimal API application

First, install the required NuGet packages:

Install-Package Refit<br>Install-Package Refit.HttpClientFactory

Now, let’s create our Refit interface:

using Refit;

public interface IBlogApi
{
    [Get("/posts/{id}")]
    Task<Post> GetPostAsync(int id);

    [Get("/posts")]
    Task<List<Post>> GetPostsAsync();

    [Post("/posts")]
    Task<Post> CreatePostAsync([Body] Post post);

    [Put("/posts/{id}")]
    Task<Post> UpdatePostAsync(int id, [Body] Post post);

    [Delete("/posts/{id}")]
    Task DeletePostAsync(int id);
}

public class Post
{
    public int Id { get; set; }
    public string Title { get; set; }
    public string Body { get; set; }
    public int UserId { get; set; }
}

We define our IBlogApi interface with methods for all CRUD operations: GET (single and list), POST, PUT, and DELETE. The Post class represents the structure of our blog posts.

Then you have to register Refit in your dependency injection container:

using Refit;

builder.Services
    .AddRefitClient<IBlogApi>()
    .ConfigureHttpClient(c => c.BaseAddress = new Uri("https://jsonplaceholder.typicode.com"));

Finally, we can use IBlogApi in our Minimal API endpoints:

app.MapGet("/posts/{id}", async (int id, IBlogApi api) =>
    await api.GetPostAsync(id));

app.MapGet("/posts", async (IBlogApi api) =>
    await api.GetPostsAsync());

app.MapPost("/posts", async ([FromBody] Post post, IBlogApi api) =>
    await api.CreatePostAsync(post));

app.MapPut("/posts/{id}", async (int id, [FromBody] Post post, IBlogApi api) =>
    await api.UpdatePostAsync(id, post));

app.MapDelete("/posts/{id}", async (int id, IBlogApi api) =>
    await api.DeletePostAsync(id));

What I love about this setup is its simplicity. We’ve created a fully functional API that communicates with an external service, all in just a few lines of code. No manual HTTP requests, no raw JSON handling – Refit takes care of all that for us.

Remember, while Refit makes API interactions more straightforward, it’s not a substitute for understanding the underlying principles of RESTful communication and HTTP.

That’s all for today. Stay awesome, and I’ll see you next week.