API Rest en C#

 

Debido a que los tiempos están cambiando, las empresas, gracias a dios, ya no realizan una aplicación gigantesca que lo hace todo, sino que esa misma aplicación está dividida en diferentes módulos o pequeños proyectos que realizan cada uno una función específica.

El uso de pequeños proyectos para hacer una aplicación más grande la denominamos arquitectura de microservicios, para la que haré un vídeo más adelante. El motivo por el que menciono esta arquitectura aquí es porque los microservicios se nutren o se basan en APIs.

 

1 - Qué es una API?

Hay varias formas de definir qué es una API. Pero yo personalmente las defino de la siguiente manera: Una API es el punto de entrada del exterior a tu proyecto.

Por supuesto lo mismo se aplica cuando nosotros somos los que consumimos diferentes API’s.

Como vemos en la imagen, tenemos nuestro front end, el cual consume al back end a través de una API, y a su vez el back end consume otros dos servicios a través de APIs.

Una API puede devolver tanto un solo carácter, como una lista con miles de elementos.

 

2 - Tipos de API en C#

En C# disponemos de dos opciones para crear APIs los cuales son SOAP y REST.

Ambas opciones tienen diferentes características pero el objetivo final es el mismo, enviar información entre un cliente y un servidor.

2.1 - Diferencias entre  SOAP y REST

Hay muchas diferencias, suficientes para hacer un post únicamente con ellas, pero voy a enumerar las uqe me parecen más importantes: 

A - Protocolo

Una gran diferencia es que SOAP es un protocolo, mientras que REST es una arquitectura que funciona sobre el protocolo HTTP.

B - Desarrollo

Desarrollar un servicio SOAP requiere de más tiempo, tanto para el cliente como para el servidor, ya que debemos crear un fichero .wsdl el cual es un XML que contiene los datos que necesita y la dirección de donde esta ese servicio web. El formato `.wsdl` nos permite además añadir un dtd el cual puede validar todos los campos del xml antes de enviar el mensaje. 

 

Por otra parte en REST funciona por el protocolo HTTP lo que implica que para recibir/enviar información debemos hacerlo a través de peticiones web, a través de la URL o utilizando el cuerpo del mensaje. Para el cuerpo del mensaje utilizamos Json o XML. Pero a diferencia de SOAP, todas las validaciones serán en el servidor. 

Por estos motivos el desarrollo de una API REST es mucho más rápido que el de un servicio web SOAP.

Por supuesto SOAP proviene de ventajas en otros aspectos, Por ejemplo, es capaz de mantener el estado entre varias request, mientras que en REST cada reques es individual. 

Y debido al apartado mencionado antes, del fichero wsdl con el xml y el dtd los servicios SOAP son mucho más seguros. 

 

3 - Creación de una API en C#

Para crear una API Rest en C# es muy sencillo, únicamente debemos crear un nuevo proyecto web.

Y como tipo, escogemos API, podemos elegir tanto vacío (empty) como aplicación web (web application) o incluso  web application (MVC) la única diferencia es que vienen con más o menos funcionalidades por defecto. 

Para el ejemplo yo he elegido un proyecto vacío

 

Antes de continuar, decir que en NetCore disponemos de un middleware el cual nos permite configurar endpoints en la clase startup.cs pero por ahora lo vamos a "ignorar", ya que es un punto más avanzado. 

 

Cuando creamos APIs debemos crear los endpoint con CRUD en mente.

3.1 - Qué es CRUD?

CRUD es un acronimo que hace referencia a sus siglas como 

• Create (crear) para el que utilizaremos el método HTTP POST.
• Read (leer) Para el que se utiliza el método HTTP GET.
• Update (actualizar) para el que utilizaremos HTTP PUT.
• Delete (eliminar) Para el que utilizaremos HTTP DELETE. 

hay más métodos HTTP pero el 99.9% de las acciones se realizan con ellos. 

 

En C# Nuestro punto de entrada serán los controladores.

Para ello, debemos asegurarnos que dentro de la clase startup.cs tenemos el servicio que añade a los controladores.

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers();
}

Y en esta misma clase en el método configure, dentro de UseEndpoints debemos indicar que busque estos endpoints en los controladores con la condición endpoints.MapControllers().

app.UseEndpoints(endpoints =>
{
    endpoints.MapGet("/", async context =>
    {
        await context.Response.WriteAsync("Hello World!");
    });
    endpoints.MapControllers();
});

3.2 - Creación de los endpoints

En C# Cuando creamos endpoints para una API lo hacemos en un controller, por ello crearemos una clase controlador EjemploController y le añadiremos el Atributo [ApiController]  y debemos importar la librería using Microsoft.AspNetCore.Mvc;

[ApiController]
public class EjemploController : Controller
{
}

Nota: recordad que los controllers deben extender siempre de Controller.

Y ahora solo nos queda la creación de los endpoints tanto para leer como para escribir.

 

A - Creación de un endpoint GET en C#

Un endpoint GET es el que utilizaremos para leer y es muy sencillo, únicamente debemos crear un método, y decorar este método con ya bien sean los atributos `[HttpGet]` para indicar el método  HTTP para utilizar junto con `[Route(“ruta”)]` para indicar la ruta, o directamente [HttpGet(“ruta”)] que nos permite indicar el método HTTP y la ruta que el navegador va a necesitar para ser llamado.

[HttpGet("nombre/{id}")]
public string LeerNombre(int id)
{
    return id switch
    {
        1 => "Net",
        2 => "mentor",
        _ => throw new System.NotImplementedException()
    };
}

Como podemos observar podemos indicar variables en la ruta poniendo los corchetes

Y posteriormente llamaremos al endpoint con el navegador https://localhost:44303/nombre/1

B - Creación de un endpoint POST en C#

Utilizamos un endpoint POST para actualizar datos, definiremos la ruta igual que en el caso de GET, pero a diferencia de este, debemos mandar información en el cuerpo del mensaje.

Por supuesto sin olvidar que debemos indicar el atributo como [HttpPost(“ruta”)].

[HttpPost("insertarempleado")]
public int InsertarEmpleado(Empleado empleado)
{
    ///Codigo de insertar empleado en la base de datos
    return 1;
}

public class Empleado
{
    public string Nombre { get; set; }
    public string Apellido { get; set; }
}

Esta información va ser un objeto el cual podemos mandar en formato json o en formato xml, y para enviarla podemos utilizar cualquier aplicación que nos permita enviar mensajes sobre el protocolo HTTP, pero la más común es postman.

 

Debemos configurar un poco la aplicación, especificando los siguientes puntos

1. Método HTTP.
2. Url destino.
3. Body en formato raw, e indicar que es un json.
4. El propio body.
5. Asegurarnos de que en los headers, tenemos el siguiente Content-Type como application/json.
6. Finalmente después de enviar la request, podemos ver el resultado en el apartado body de la response. 

C - Resto de escenarios

Para el resto de escenario es lo mismo, únicamente debemos cambiar el método por el que deseemos así como el cuerpo del mensaje.

 

Otros

Antes de terminar quiero comentar otro punto, y es que es muy común utilizar el nombre del controller como parte de la URL. como hemos visto en el ejemplo anterior esto no es 100% obligatorio, pero si es una práctica común.

Para utilizar el controller como parte de la url, no debemos modificar cada uno de nuestros métodos para añadir el controlador, sino que la propia clase tiene su decorador al que le podemos indicar la ruta con [Route("[controller]")] siendo `controller` la propia palabra controller, no el nombre de ese controller, aunque obviamente lo podemos modificar. 

[ApiController]
[Route("[Controller]")]
public class EjemploController : Controller
{
   //metodos 
}

Conclusión

Tener claro que es una API es esencial en el mundo laboral actual. 

Trabajamos con APIs todo el tiempo, ya bien sea porque nuestra arquitectura es de microservicios, o porque consumimos o somos proveedores de servicios API. 

Saber diferenciar las características o diferencias entre SOAP y REST puede marcar una diferencia en términos de diseño muy importante. 

Utilizar APIs además ayuda al desarrollo, ya que, por norma general, el código es más pequeño, lo que implica más fácil de testear y en caso de tener algún bug es más fácil arreglarlo. 

Finalmente, gran parte de las entrevistas que tendréis para puestos mid o senior incluirán una parte de hacer una API en código o definir una API en una pizarra.