Ya hemos llegado a la recta final, resumiendo nuestro recorrido en esta serie, pudimos aprender los conocimientos teóricos necesarios para entender el comportamiento de las APIs, como preparar nuestro entorno de desarrollo, conocer la estructura de un API, por último, en nuestro articulo anterior vimos una breve introducción al modelo MVC(Modelo Vista Controlador) y empezamos a escribir nuestras primeras lineas de código. Sin embargo, aun nos resta la roca pilar, los controladores.

Acompáñame en el último artículo de esta serie y descubre como crear tus propios controladores.

Si te perdiste alguno de estos artículos esta es la secuencia:

  1. Serie: Desarrolla tu primer API REST en Asp.Net Core (Conocimientos previos)
  2. Serie: Desarrolla tu primer API REST en Asp.Net Core (Prepara tu entorno)
  3. SERIE: DESARROLLA TU PRIMER API REST EN ASP.NET CORE (Conoce la Estructura de un API )
  4. SERIE: DESARROLLA TU PRIMER API REST EN ASP.NET CORE(CREA TU PRIMER API)

Antes de empezar a escribir el código de nuestros controladores, debemos saber cual es su función y que son realmente. Bajo el patrón MVC, controladores es donde se encuentra la lógica del negocio, y se comportan según las interacciones del usuario. Debemos saber que los controladores son clases que por convención tiene el prefijo- del [nombre del modelo] en plural y sufijo–  [controller].

Bajo el modelo de APIs el comportamiento no es muy distinto, la diferencia más notoria, es que no interactuamos con estos por medio de vistas, debido a que carecen de estas por su propia naturaleza, para probar el comportamiento de nuestra API, usaremos la aplicación Postman que ya hemos instalado en el Segundo articulo de esta serie.


¿Qué es un controlador?

Básicamente el rol de un controlador es responder a las peticiones del usuario, a menudo esto incurre en algún cambio en la data o modelo. Los controladores manejan el flujo de la aplicación, trabajan con la data que llega y proveen la data de respuesta, el caso tradicional bajo el patrón MVC, esto sería traducido a una vista.

Pero haremos esta idea un poquito más clara con la siguiente infografía.

web APi controller (1)

Como hemos podido apreciar existen notorias diferencias entre ambos. En estos momentos vamos a aterrizar estos conceptos viendo y entendiendo el código.

Recapitulando, en el articulo anterior creamos nuestra base de datos, por medio de scripts, configuramos nuestro connection string, ademas creamos nuestros modelos, y por supuesto nuestro contexto de base datos en DataAccess.cs, como ya hemos mencionado lo que sigue son nuestros controladores.

Como ya hemos visto un controlador es usado para definir y agrupar un conjunto de acciones que están relacionadas directamente a un modelo o entidad. De hecho por convención nombramos a los controladores de la siguiente manera [nombre entidad en plural] + Controller. Es decir, si tenemos un modelo llamado Book  y vamos a crear un controlador el nombre sería BooksController. 

Crear un controlador en ASP.NET Core es muy fácil, solo necesitas crear una clase POCO(clase pana) que herede de la clase Microsoft.AspNetCore.Mvc.Controller.

Debemos usar siempre los métodos HTPP como nombres de acciones.

La Ruta URL

Los Web client que ya hemos mencionado antes, invocan un Web API remotamente enviados solicitudes HTTP.

[Route("api/books")]
public class BooksController : Controller
{

 [HttpGet]
public IEnumerable<Book> Get()
{
// return todos los libros
}

 [HttpGet("{id}")]
public Book Get(int id)
{
// return el libro que coincida con el id }
}

Si la solicitud HTTP es la siguiente:

GET http://localhost:5000/api/products HTTP/1.1
Host: localhost:5000

Tendríamos como resultado el IEnumerable<Book> Get(), es decir esta acción sería invocada y obtendríamos una lista de Book.


unicorn   Estamos creando un Web API siguiendo las reglas de REST, por tanto, hay algunas cosas que tenemos que tener en cuenta, yo los llamo los mandamientos de REST:

  • No pondrás nombre de {actions} en la ruta de acceso a tus métodos de controlador.
  • Aprenderás a usar otro tipo de retorno ademas de Ok() y BadRequest().
  • No retornarás el código HTTP inadecuado.
  • Todos tus recursos deberán ser accesibles a través de un enfoque común, como HTTP GET.
  • Tus recursos solo podrán ser  modificados de manera similar con un enfoque coherente.

Ya que conocemos un poco la estructura y el comportamiento de los controladores es hora que empecemos a crear desde cero los nuestros. Crearemos un controlador que nos permitirá hacer un CRUD (Create, read, update y delete) con la clase autores. Para poder entender el comportamiento de esta API, sera imprescindible que la probemos vía Postman en modo Debbug.

Crea una clase llamada AuthorsController.cs y copia el código siguiente:

Ahora vamos a entender este código despacito, en la sexta linea de código,vemos la definición de un route, por el cual podremos acceder a un controlador. «api/v#/[controller], ahora bien tal vez tengamos la interrogante de como vamos a acceder a cada uno de los métodos de nuestra API, si no hay nada en nuestra ruta que los diferencie, como ya hemos estado acostumbrados en modelos tradicionales.

Si observamos con detenimiento, podemos observar que cada método usa un verbo HTTP, lo cual indica el tipo de acción a realizarse en dicho método, lo cual es suficiente para la mayoría de los casos.


unicorn   Caso de Estudio

Que ocurría si tenemos dos métodos HTTP iguales y sin una ruta distinta(siguiendo el estilo de REST), cuando enviemos un parámetro usando método HTTPGet, el controlador no los va a diferenciar y va a ejecutar el primer método que encuentre.

Solución: Como queremos seguir bajo el estilo de REST,  la solución encontrada para este caso es tipear el parámetro del método HTTP Get by ID, es decir, especificar el tipo de dato que será el parámetro, de esta manera cuando el controlador reciba un parámetro de tipo Int no tendrá confusión y siempre entrará al método adecuado.(Quita esta restricción y observa que ocurre en el código.


Otro elemento que ya mencionamos pero no abundamos al respecto son los parámetros, cuando el cliente web invoca las acciones o métodos del controlador envía las solicitudes HTTP y los parámetros necesarios para que se realicen dichas acciones. De acuerdo a los parámetros que enviemos el buscará la acción que corresponda a dichas condiciones, si existe.

Las partes de los parámetros de un «Action» usualmente son las siguientes:

  1. Parámetros tipo Query
  2. Parámetros de ruta 
  3. HTTP QUERY BODY

light-bulbAtributos de los Parámetros de Acción, podemos usar [FromQuery], [FromRoute], [FromBody], para decirle al API de donde va a extraer los datos y asignar el valor al parámetro de la acción.


El siguiente comportamiento tampoco tendrá un comportamiento muy diferente al anterior, repetimos el paso anterior, en este caso con la clase Book.

Creamos una clase llamada BooksController.cs y copiamos el siguiente código:

Como ya hemos mencionado tenemos que probar nuestra API vía Postman, compilamos nuestra API en Visual Studio y procedemos a testear los endpoint de la siguiente forma:

Para el Get:

http://localhost:{your port}//api/v1/library/authors

para el get by id:

http://localhost:{your port}//api/v1/library/authors/1

Para el post:

para delete:

http://localhost:{your port}//api/v1/library/authors/{idregistro}


Puedes seguir explorando y debuggeando con el controlador Books, en esta serie de articulos vimos como es posible crear un API desde cero, usando database first. Si te ha ustado o tienes alguna duda dejame saber en tus comentarios.

Para que puedas ver este demo un poquito más de cerca dejaré por aquí el link del Repositorio en github contiene algunas modificaciones muy simples usando DTOs, además contiene los scripts necesarios para la creación de la base de datos y generación de registros. ——–> Click Aquí