Crea una API básica desde un proyecto vacío

Cuando creas un nuevo proyecto, ya sea de tipo WebApi o MVC, seguramente suelas utilizar plantillas. En muchos casos incorporan capacidad por encima de las necesarias, o condicionan tu desarrollo. No obstante es un muy buen punto de partida que se puede ajustar a tus necesidades. Suelen incluir unos controladores básicos, algunas vistas, les puedes incluir un mecanismo de autenticación y en ese caso te incluirán incluso modelo.

Sin embargo con las nuevas arquitecturas basadas en microservicios, es posible que no necesites nada de todo esto, y con unos simples servicios expuestos te sea más que suficiente para consumir la Api de un mircoservicio desde una aplicación SPA. Si este es el caso, en esta entrada te voy a mostrar como crear un proyecto de Api nuevo, sin utilizar ningún template, y haciendo uso de la clase StartUp en lugar de global.asax, como ya hacen muchos template, especialmente basados en .Net Core.

Si ya tienes experiencia en desarrollo con .Net es posible que esta entrada sea demasiado básica para ti, pero existen muchos casos donde cuando estamos iniciando nuestra experiencia como desarrolladores partimos siempre de aportar implementaciones o desarrollos a proyectos ya iniciados, y no tenemos la oportunidad de crearlo desde cero y pensar en estas cosas mas relacionadas con la arquitectura del proyecto. Si este último es tu caso, con solo 6 pasos estarás en disposición de continuar el desarrollo en un proyecto preparado para ello, que tu mismo habrás creado.

1. Creación del proyecto Web vacío

Para empezar crea un nuevo Proyecto Web ASP.Net (.Net Framework). Selecciona un nombre, decide si quieres crear un directorio y un repositorio y continua.

Al seleccionar las plantillas, escoge vacía, sin autenticación, ni marcar ninguna de las opciones Mvc, WebApi o cualquier otra, lo instalaras todo mas adelante por tu cuenta sin incurrir en instalar nada que no vayas a necesitar.

2. Instalación de paquetes Nuget

A continuación abre el administrador de paquetes nuget e instala los siguientes nugets

  • Microsoft.AspNet.WebApi
  • Microsoft.AspNet.WebApi.Owin
  • Microsoft.Owin.Host.SystemWeb
  • Microsoft.Owin.Cors
  • Unity.WebApi

Owin es la Open Web Interface para .Net, permitirá que tus servicios estén expuestos y hará mucho trabajo por ti de forma transparente, como mapear los objetos de entrada a cada uno de tus parametros de los endpoints por ejemplo, entre otras muchas cosas.

Con estos nuget estarás listo para crear una clase StartUp desde la que lanzar tu aplicación en un servidor IIS, exponer tus servicios en controladores que hereden de ApiController, habilitar Cors para consumir tu Api desde otro dominio y preparar Unity para usar una arquitectura con DI (Dependency Injection).

Podrás añadirle opciones mas adelante según tus necesidades, como swagger, identity… para ello podrás encontrar información en otras de mis entradas.

3. Editar clase de UnityConfig

Lo de este paso es una cuestión más relacionado con los gustos personales que con un aspecto puramente técnico.

Se trata de editar la clase creada por defecto al instalar unity para que permita devolver un contenedor y además podamos decidir si configurar las dependencias desde código en este método o con una configuración a través de web.config, de forma que podría modificarse en caliente sobre la maquina sobre la que la aplicación ha sido desplegada.

4. WebApi config

Al instalar unity se te habrá creado una carpeta App_Start, dentro de esta carpeta vas a crear la clase WebApiConfig con el siguiente contenido:

5. Creación de la clase startup

A continuación vas a crear la clase StartUp desde la que tu aplicación se va a lanzar.

6. Exponer un servicio a través de un controlador

Por último, un controlador muy simple basado en los ejemplos de los templates que sueles instalar.

Crea una carpeta Controllers con una clase ValuesController como la siguiente:

Conclusiones

Una Api muy básica, creada desde 0 en 6 pasos muy simples, para que tus microservicios sean de verdad micro.

Al arrancar tu servicio no tendrás una bonita vista, de hecho tendrás una vista 403, pero añades a la url “/api/values” podrás ver el resultado devuelto por tu controlador, value1 y value2.

A partir de aquí hay mucho trabajo por delante:

  • Como ya he comentado antes podrías instalar swagger para documentar tu Api como explico en esta entrada.
  • Usar una capa de servicio para tu lógica que sea llamada directamente desde tus controladores, evitando así que tu aplicación este ligada a una WebApi y puedas aplicar esa misma lógica en una arquitectura Mvc por ejemplo.
  • Aislar tu capa de servicio de tus capas de dominio y datos con patrones como Unit Of Work o Repository Pattern, como presento en esta otra entrada.
  • Aplicar seguridad si necesitas que tus métodos usen autenticación, u ofrecer generación de token OAuth v2 si tu microservicio va a ser el que utilicen tus usuarios para registrarse en tu app.

Este como puedes ver, es solo el punto de partida para no tener algo que condicione tus desarrollos.

Puedes descargar el proyecto de mi Git en este enlace. Una práctica que espero poder tomar por costumbre en el resto de mis entradas si el tiempo libre lo permite.

Un saludo.

 

Deja un comentario