![\"\u00bfC\u00f3mo](\"http:\/\/blogs.encamina.com\/piensa-en-software-desarrolla-en-colores\/wp-content\/uploads\/sites\/21\/2018\/01\/\u00bfComo-versionamos-nuestra-API-en-ASP-.NET-Core.png\")
<\/p>\n<\/p>\n
A la hora de desarrollar nuestra API, hay algunos aspectos que debemos de tener claros antes de empezar a tirar lineas de c\u00f3digo: autenticaci\u00f3n, versionado, CORS, nomenclatura, escalado, etc… En este post vamos a a ver c\u00f3mo versionar nuestra API en ASP.Net Core<\/strong>.<\/p>\n <\/p>\n Antes de entrar en materia, vamos a poner un poco de contexto. Tenemos la tarea de desarrollar una API para una organizaci\u00f3n que va a dar cobertura a determinados requerimientos de negocio.<\/p>\n Esta API se utilizar\u00e1 desde varias aplicaciones, tanto m\u00f3viles como de escritorio, y desde entornos Windows y No-Windows). Publicamos la primera versi\u00f3n de nuestra API con todos estos requerimientos, la ponemos en producci\u00f3n, y todas estas aplicaciones se ponen a funcionar y a consumirla sin ning\u00fan problema. Ahora bien, puede llegar un momento en que surja una nueva necesidad en la organizaci\u00f3n, o bien cambie alguno de los requisitos de negocio. En este caso, est\u00e1 claro que tenemos que hacer una modificaci\u00f3n en nuestra API y quiz\u00e1s alguno de los m\u00e9todos de las aplicaciones utilizadas hayan cambiado. De ser as\u00ed, en el momento en que actualicemos las API, es posible que alguna de las aplicaciones que nos consumen dejen de funcionar. \u00bfC\u00f3mo podemos solucionar este problema<\/strong> y no dejar sin servicio a algunos de los clientes de nuestras API?:\u00a0Versionando nuestra API<\/strong><\/p>\n En versiones anteriores, el framework no ten\u00eda nada de serie para hacer versionados de la API, y para conseguirlo hab\u00eda que hacerlo de forma manual. Dependiendo de las necesidades que tuviera esa API, se implementaban unas rutas en cuya petici\u00f3n se\u00a0 inclu\u00eda la versi\u00f3n requerida, siguiendo el resto de procesos de forma manual. Un buen ejemplo para saber c\u00f3mo versionar de\u00a0 forma correcta en versiones anteriores, la escribi\u00f3\u00a0 Sergio Le\u00f3n<\/a>\u00a0 en el siguiente art\u00edculo.<\/a><\/p>\n Ahora, el equipo de .NET ha publicado un paquete Nuget para facilitarnos todas estas tareas con el versionado de la API<\/strong>. A la consola de ejecuci\u00f3n le a\u00f1adimos el paquete de Nuget donde disponemos un middleware para utilizar en nuestro proyecto: Con el paquete de Nuget a\u00f1adido, el siguiente paso es poner este middleware dentro del punto de arranque. Para ello, en el Startup.cs\u00a0 (m\u00e9todo ConfigureServices), a\u00f1adiremos las siguientes l\u00edneas:<\/p>\n Dentro de estas opciones: Ahora bien, al configurar estos par\u00e1metros tenemos que tener clara cu\u00e1l es la estrategia que vamos a dar a los consumidores de nuestra API para consultarla: si ser\u00e1 un par\u00e1metro de la petici\u00f3n REST, o\u00a0 si vamos a a\u00f1adir una \u00abheader\u00bb en dicha petici\u00f3n para seleccionar la versi\u00f3n de la API.<\/p>\n Yo personalmente prefiero utilizar el header<\/strong>. El primer motivo, por seguridad (dar informaci\u00f3n extra a posibles usuarios no aporta valor). El segundo, es que si hacemos uso de una petici\u00f3n y \u00e9sta cambia, tengo que modificar las llamadas en la aplicaci\u00f3n que lo consume (como se nota el uso de la API Graph, que cada vez que cambia de versi\u00f3n tengo que llevar a cabo modificaciones en diversas aplicaciones).<\/p>\n Otro de los aspectos que se configuran en el middleware es indicar si asumimos la versi\u00f3n por defecto, en caso de que no venga informada. En este caso, como creador de una API<\/strong>, me parece buena idea partir de dicha base. Ahora bien, como posible consumidor de dicha API<\/strong>, el hacer llamadas sin versionar puede ocasionar\u00a0 problemas en la llamada, ya que si la API modifica la devoluci\u00f3n de la misma, esto ocasiona que mi aplicaci\u00f3n deje de funcionar.<\/p>\n Una vez tenemos el middleware configurado, el siguiente paso ser\u00eda a\u00f1adir la versi\u00f3n que vamos a utilizar dentro de cada controlador de nuestra WebAPI.<\/p>\n En caso de que queramos poner la versi\u00f3n en la llamada de la petici\u00f3n, lo har\u00edamos bajo el Atributo Route, de la siguiente forma:<\/p>\n Otro de los aspectos que nos proporciona este paquete de Nuget es poder indicar que un m\u00e9todo esta deprecated<\/em> y que pase a utilizar otra versi\u00f3n. Para ello, bastar\u00eda con poner lo siguiente en la cabecera de dicho m\u00e9todo:<\/p>\n A\u00f1adiendo esto en la devoluci\u00f3n de la petici\u00f3n, se devolver\u00e1 en los headers lo siguiente: El versionado de la API es algo muy importante y que debemos de plantearnos desde el minuto cero de la creaci\u00f3n de la API.<\/p>\n Est\u00e1 claro que el utilizar esta librer\u00eda de Nuget nos ahorra muchos quebraderos de cabeza a la hora de mantener una comunicaci\u00f3n con nuestros clientes. Pero independientemente de si utilizamos la librer\u00eda o no, debemos tener clara la estrategia a seguir.<\/p>\n Esta librer\u00eda nos facilita la comunicaci\u00f3n entre la API y sus consumidores, sin embargo, debemos tener en cuenta c\u00f3mo vamos a llevar el versionado del resto del backEnd. Por ejemplo, si\u00a0 a\u00f1adimos un nuevo identificador sobre la base de datos y esto provoca que la versi\u00f3n anterior deje de funcionar. En este caso, debemos tener en cuenta si \u00e9sto lo vamos a soportar o no. Otros aspectos que tambi\u00e9n hay que prever, es a cu\u00e1ntas versiones\u00a0 anteriores se da soporte y cu\u00e1l es la pol\u00edtica de incremento de versi\u00f3n de la API (si voy a subir de versi\u00f3n cuando haya un nuevo requisito, o bien cuando haya una nueva Feature).<\/p>\n Y vosotros, \u00bfc\u00f3mo version\u00e1is vuestra API?<\/p>\n Happy Codding \ud83d\ude42<\/p>\n<\/span>","protected":false},"excerpt":{"rendered":" A la hora de desarrollar nuestra API, hay algunos aspectos que debemos de tener claros antes de empezar a tirar lineas de c\u00f3digo: autenticaci\u00f3n, versionado, CORS, nomenclatura, escalado, etc… En este post vamos a a ver c\u00f3mo versionar nuestra API … Continue reading C\u00f3mo se hac\u00eda en versiones anteriores de ASP.NET<\/strong><\/h2>\n
\u00bfC\u00f3mo se hace en .NET Core?<\/strong><\/h2>\n
\nDotnet add package Microsoft.AspNetCore.Mvc.Versioning<\/p>\n\r\n services.AddApiVersioning(options =&gt;\r\n {\r\n options.ReportApiVersions=true;\r\n options.AssumeDefaultVersionWhenUnspecified = true;\r\n var multiVersionReader = new HeaderApiVersionReader("x-version"); \r\n options.ApiVersionReader= multiVersionReader;\r\n options.DefaultApiVersion = new ApiVersion(1, 0);\r\n });\r\n<\/pre>\n
\n– ReportApiVersion<\/strong> -> Indica que en la petici\u00f3n se\u00f1alamos\u00a0 qu\u00e9 versi\u00f3n de la API soporta la petici\u00f3n que hemos realizado.
\n– AssumeDefaultVersi\u00f3nWhenUnspecified<\/strong> ->En caso de que no se notifique la versi\u00f3n en la petici\u00f3n, c\u00f3mo tratamos dicha petici\u00f3n (si se env\u00eda un error o bien si asume la versi\u00f3n por defecto).
\n– ApiVersi\u00f3nReader<\/strong> -> Ubicaci\u00f3n donde indicamos la versi\u00f3n, ya sea por QueryString o por HeaderAPIVersi\u00f3n
\n– DefaultApiVersi\u00f3n<\/strong> -> Versi\u00f3n por defecto la API<\/p>\n\r\n [ApiVersion("2.0")]\r\n public class StarWarsController : Controller\r\n {\r\n<\/pre>\n\r\n[ApiVersion( "1.0" )]\r\n[Route( "api\/v{version:apiVersion}\/[controller]" )]\r\npublic class HelloWorldController : Controller {\r\n public string Get() =&gt; "Hello world!";\r\n}\r\n<\/pre>\n\r\n[ApiVersion( "2.0" )]\r\n[ApiVersion( "1.0", Deprecated = true )]\r\n<\/pre>\n
\n![\"\"](\"http:\/\/blogs.encamina.com\/piensa-en-software-desarrolla-en-colores\/wp-content\/uploads\/sites\/21\/2018\/01\/blogheaders.jpg\")
<\/p>\nConclusi\u00f3n<\/strong><\/h2>\n