El mundo de los REST Services está en todos lados. Siempre tendrás la necesidad de consumir un Web Service desde cualquier lenguaje, más ahora con la moda que tienen los Microservicios.

La forma tradicional de hacer esta tarea es escribiendo los clases necesarias (modelos) y hacer las llamadas con HttpClient o RestSharp y serializar la respuesta a los modelos correspondientes.

Hay veces que son muchos los métodos y modelos que hay que estar mapeando manualmente y pues si tenemos el control, lo mejor es configurar Swagger para generar un OpenAPI Document (que esto es tema de otro post 😅) y tener todo en automatico.

Pero si no existe Swagger, aquí entra RestEase como una alternativa. Es una librería que te ayuda a consumir servicios de una forma super sencilla sin tener que implementar nada, solo creamos el contrato (una interfaz), sus modelos (no nos salvamos de esto) y le decimos a RestEase los endpoints y listo!.

Para hacer este ejemplo, podemos empezar con un proyecto en consola:

dotnet new console -o RestEaseExample

Podemos instalar ReastEase desde su NuGet:

dotnet add package RestEase

La idea es consumir cualquier REST Service, en este ejemplo usaremos la API de GitHub y el método Get User .

Este Endpoint regresa un JSON con mucha información, pero solo nos interesa lo más básico para fines del ejemplo:

Para eso, necesitamos crear el modelo User:

using System;
using Newtonsoft.Json;

namespace RestEaseExample
{
    public class User
    {
        public string Name { get; set; }
        public string Blog { get; set; }
        [JsonProperty("created_at")]
        public DateTime CreatedAt { get; set; }
    }
}

Aquí lo único importante a destacar es el atributo JsonProperty de Json.NET y lo que hace es mapear el campocreated_at (que se encuentra en el JSON) a la propiedad CreatedAt, con las otras propiedades no es necesario hacer eso ya que se llaman igual.

Para poder usar RestEase, necesitamos crear una interface para aquí especificar los endpoints del Web Service, en este ejemplo, solamente el método GET users/{userId}:

using System.Threading.Tasks;
using RestEase;

namespace RestEaseExample
{
    [Header("User-Agent", "RestEase")]
    public interface IGitHubApi
    {
        [Get("users/{userId}")]
        Task<User> GetUserAsync([Path] string userId);
    }
}

Esta interface representa las acciones de la API (si vemos en la documentación, hay cientos de métodos que podemos llamar). El atributo Header nos sirve para especificar HTTP Headers customs que queramos incluir, en el ejemplo simplemente estamos indicando el User-Agent con valor de RestEase.

Si vemos el repositorio de ReastEase (donde viene incluido este ejemplo) podemos ver los distintos usos que podemos darle a los atributos. Claro podemos crear métodos POST, PUT, DELETE, etc. Pero también podemos indicar la forma de mandar datos, ya que en este ejemplo usamos el atributo Path para indicar que el parámetro userId va incluido en la ruta GET (y como se dan cuenta, la ruta misma indica donde irá el valor). Pero puede ser Body o Query dependiendo donde queramos mandar los datos en la solicitud HTTP.

Finalmente para poder llamar a la API de GitHub:

using System;
using System.Threading.Tasks;
using RestEase;

namespace RestEaseExample
{
    class Program
    {
        static async Task Main(string[] args)
        {
            IGitHubApi api = RestClient.For<IGitHubApi>("https://api.github.com");

            User user = await api.GetUserAsync("isaacOjeda");

            Console.WriteLine($"Name: {user.Name}. Blog: {user.Blog}. CreatedAt: {user.CreatedAt}");
            Console.ReadLine();
        }
    }
}

Así de fácil se pudo crear un cliente HTTP para consumir una API en .NET Core y C#.

Esto es muy útil cuando trabajamos en microservicios y es muy común estar escribiendo las llamadas HTTP manualmente, pero realmente puede ser útil en cualquier escenario.

El resultado al correr la aplicación es el siguiente:

❯ dotnet run
Name: Isaac Ojeda. Blog: https://dev.to/isaacojeda/. CreatedAt: 09/10/2012 04:49:07 p. m.

Esto se puede integrar con HttpClientFactory, pero este lo dejaremos para el siguiente post 🙂

Code4Fun!