Este 18 de enero he tenido la suerte de participar en la primera NetCoreConf celebrada en Barcelona. El evento, para ser el primero del año, deja el listón muy alto con casi 300 asistentes ¿Mi valoración?: sencillamente espectacular 🙂
Empezando por el sitio, continuando por los asistentes (muy participativos y que llenaron las salas hasta última hora de la tarde), pasando por los speakers (son muchos los eventos en los que coincidimos, muchas ratos en las sala de speakers, dándonos ánimos, ayudándonos… y todo eso es gracias al buen rollo y la química que reina entre nosotros), y naturalmente, sin olvidarnos de los patrocinadores 🙂 Desde ENCAMINA es parte de nuestra RSC apoyar y aportar nuestro granito de arena a estos eventos, porque están alineados con nuestros ideales y porque estamos convencidos de que nuestro mayor valor reside en compartir nuestro talento con el mundo. Y ya por último, no me puedo olvidar de darle las gracias a la pedazo de organización que se ha pegado un currazo enorme ¡GRACIAS, gracias y gracias Robert, Txema y Manu!
Y ahora sí, para todos lo que no pudísteis asistir, voy a intentar desgranar un poco el contenido de la charla que di:
Cómo crear una API REST como un Avenger
La idea de esta charla surgió cuando en un proyecto de los que realizamos el año pasado a un compañero le tocó la tarea «fácil» de darle forma a una API. Muchas veces se piensa que es algo relativamente simple porque solo supone poner 4 métodos sin ninguna complejidad, pero en ese pensamiento obviamos mucha parte del trabajo. La definición de una API es una tarea bastante importante.
Por un lado hay que definir un Contrato para que los usuarios/cliente de la API lo puedan usar. Tiene que tener unos aspectos de seguridad para evitar que el desarrollo cuando la aplicación termine en un entorno productivo no sufra ningún percance. Pero no obstante, para mí uno de los aspectos más importantes que tiene, es precisamnete que tiene un aspecto NO técnico, que es el sentido común y que hay que aplicarlo.
Partiendo de esta condición, la charla la dividí en 5 grandes puntos:
Nomenclatura =>
Naturalmente pueda parecer que como se tiene que llamar los endpoints de la API es algo sencillo. Pero es importante que los equipos de desarrollo tengan claro cuál es la nomenclatura que se utiliza para que todos la sigan. Es recomendable seguir unas «buenas prácticas» para tener una API «consistente»:
- Usar slash (/) para indicar relación jerárquica
- No usar slash(/) para finalizar la petición
- Usa (-) para mejorar la legibilidad de la URI
- No usar (_)
- Usar letras minúsculas en las URI
- No usar extensión de ficheros
Documentación =>
Éste es uno de los puntos débiles de todos los desarrolladores, pero en el tema de la creación de la API es todavía más importante. ¿Por qué? El motivo es claro. Si no tenemos nuestra API, los usuarios de la misma no van a poder consumirla porque no van a saber los métodos que tienen que llamar, qué parámetros se espera de entrada y de salida. En la sesión vimos cómo de la misma forma en la que empezamos el desarrollo, podemos empezar a documentar la API usando una utilidad llamada Swagger y cómo debemos configurar los middleware en .NET Core para que se muestre toda la información.
Versionado=>
Otro de los puntos que solemos olvidar es versionar la API nuestros métodos. A mi parecer es bastante importante incluirlo desde la versión inicial porque no es algo que nos cueste mucho, y hacerlo más adelante (cuando queramos hacer la versión dos), quizá sea demasiado tarde para alguna de las decisiones que se hayan tomado en el proyecto. Sobre cómo versionar en .NET Core ya escribí hace unos meses en este blog.
Odata =>
El uso de OData es algo que muchos asistentes a la sesión no habían utilizado. Para mi gusto, la utilización de OData para todo el tema de filtrado de datos y paginación de los mismos, es una utilidad muy sencilla y simple. Podéis leer una introducción a la misma en el artículo que escribió mi compañero Sergio Parra.
Autenticación y Autorización=>
Aunque éste es el último punto de la charla, para mí la seguridad de la API es algo que debemos de hacer en primer lugar y antes que nada. Muchas veces comparamos el desarrollo software con la construcción, pues bien, pensad en esta metáfora: si en tu casa no hay puerta ¿por dónde entrarías? Pues con la seguridad en la API, es exactamente igual.
Podéis ver la presentación de la charla que he subido a mi canal de SlideShare y el código de la demo que realicé esta en este repositorio de GitHub (junto con una colección de Postman para que podáis hacer las llamadas).
¡¡Happy coding !!
¡Suscríbete a nuestras RRSS!
