Integración de Web Apis en MVC
Una Web Api es una arquitectura que nos permite crear servicios Rest conforme a todos los estándares.
Se utiliza siempre una URL para saber qué datos quiero obtener. Además, Web Api se fundamenta en toda la estructura de MVC.
MVC es una arquitectura para el desarrollo de aplicaciones web. Separa las aplicaciones en tres capas: Modelo (estructura de datos), Vista (interfaz de usuario) y Controlador (encargado de responder las peticiones del cliente). Esta forma permite que sea mucho más sencillo su mantenimiento, testing etc.
Un punto importante a la hora de crear una Web Api es usar Entity Framework. Con esta tecnología podremos crear una “capa” que contendrá todos los métodos para manipular una base de datos.
Al ejecutar la Web Api el navegador nos mostrará un error. Esto sucede porque la Web Api no tiene un Front End pero sí que está corriendo por detrás. Por tanto, para visualizar los datos, simplemente añadimos a la url: /api/NombreController. Un ejemplo de uso sería el siguiente, http://localhost:59969/api/Libros.
Para hacer llamadas a las Web Apis podemos usar código del lado del servidor o código del lado del cliente.
Al crear la Web Api y la aplicación web deberíamos usar inyección de dependencias. Esta herramienta básicamente lo que hace es colocar dentro de un objeto otros que puedan cambiar su comportamiento sin que esto implique volver a crear el objeto.
Para ello, podemos usar Unity (desarrollado por Microsoft). Unity es, por tanto, un framework de inyección de dependencias.
En la Web Api debemos usar el paquete Unity.WebApi, encargado de la base de datos. Y en la aplicación web debemos usar Unity.Mvc, encargado de los servicios.
Al configurar Unity es recomendable crear la clase “Bootstraper” y hacerlo ahí, y así, si por algún motivo reinstalamos Unity, evitamos perder todos los datos de configuración.
Si creamos una aplicación web que consuma datos de la Api a través del lado del cliente y estas están en diferentes dominios tenemos que tener especial cuidado con el CORS (cross-origin resource sharing). La finalidad del CORS es permitir el acceso a dominios diferentes para consumir recursos. Por tanto, al crear la Web Api debemos habilitar el CORS.
En los controladores de la aplicación he autorizado a todos los dominios acceder a la Web Api si solo queremos permitir el acceso a un dominio en concreto en origins debemos cambiar ‘*’ por el dominio que queramos permitir el acceso. Si quisiéramos ser más estrictos, incluso podemos permitir un header y un método (GET, POST, PUT, DELETE) en concreto.
Si por el contrario, la aplicación la creamos a través del lado del servidor no haría falta habilitar el CORS.
En la aplicación del lado del servidor el servicio REST es un cliente HTTP genérico que devuelve una cadena de texto así que para trabajar con esos datos hay que serializarlos y deserializarlos.
Si aun así os queda alguna duda podéis consultar el código del videotutorial a través de mi cuenta de “Git Hub”. A continuación os dejo las URL de mi cuenta y de las aplicaciones:
- Perfil: https://github.com/felixMA1/
- Web Api: https://github.com/felixMA1/ApiBiblioteca
- Aplicación cliente: https://github.com/felixMA1/ClienteApiBiblioteca
- Aplicación servidor: https://github.com/felixMA1/ServidorApiBiblioteca
Para finalizar, yo os recomendaría consumir las Web Apis desde el lado del servidor. De este modo podéis evitar bastantes problemas ya que si creamos nuestra aplicación desde el lado del cliente ese código lo puede ver cualquiera. ¿Vosotros que pensáis?
Félix Martínez Alvaro
Alumno de Microsoft MCSD
Centro Tajamar
Curso 2015-2016