Definición de un ecosistema de herramientas Open Source y estándares abiertos para la construcción de servicios web REST

Cada día es más común que los proyectos de desarrollo (y sobre todo los de integración) se midan en semanas e incluso días en lugar de meses. Los plazos de entrega cada vez son más cortos y esto se debe a que el mercado está cambiando y las necesidades caducan. Esto significa que las ideas carecen de valor fuera de la ventana de tiempo en las que fueron concebidas. Sin duda, las metodologías ágiles ayudan mucho a cumplir estos nuevos plazos, aunque yo soy de los que piensan que la mejor metodología es la del sentido común y que la radicalización de las cosas, en un sentido u otro, no suele traer nada bueno. En realidad siempre hay un trabajo que realizar y la eficiencia con la que se realiza éste, depende de lo apropiadas que sean las herramientas empleadas. En los proyectos de integración se hace más necesario si cabe que los equipos de desarrollo estén coordinados y que esta labor de coordinación no consuma un tiempo excesivo. Para esto es necesario contar con herramientas que minimicen las pérdidas de eficiencia en los ciclos de desarrollo y que eviten que los desarrolladores dediquen tiempo a tareas repetitivas. Los estándares y fuentes abiertas se han demostrado como una alternativa muy potente que solventan esta necesidad y en las que colaboran grandes corporaciones que han reorientado su forma de entender el negocio. En el mundo de la integración, los servicios web tienen un papel clave por su versatilidad, cuestión que todavía se ve mejorada por la simplicidad de uso e interpretación de los servicios web REST. En este tipo de proyectos no solo hay que coordinar a los miembros del equipo de desarrollo sino que también hay que establecer una forma de operar entre publicadores y consumidores del Servicio/API RESTful. Documentar la especificación de estos servicios es una tarea ardua, que requiere replicar partes del desarrollo y que por lo general tiene muchas similitudes con otros proyectos. Esto lleva a intentar reaprovechar cosas de forma manual con el consiguiente riesgo de cometer errores. Todo esto plantea una pregunta al respecto de los servicios/API RESTful. ¿Cómo es que algo que se ha demostrado tan útil, potente y versátil puede ser tan ambiguo en lo que a especificación se refiere?. ¿No debería haber algo que regule y ponga de acuerdo a productores y consumidores al respecto de cómo consumir y publicar estos servicios?, pues si, lo hay, y es el objeto de este trabajo. ABSTRACT. Each an every day is more common for development projects (and especially those related to integration) to be measured in weeks or even days instead of months. The delivery dates are getting shorter and shorter every day and this is due to changes in the market and client’s necessities which change maybe even faster. The latter refers to a simple concept in which ideas have absolutely no value unless they’re taken into action or effect in a specific time range. It’s without a doubt that agile methodologies do help achieve the required delivery dates, even though I’m one of those who think the best methodology comes from common sense and that radical measures in one sense or the other will never bring up something positive or good. In fact there’s always a task to be accomplished in which its efficiency depends on how the appropriate tools are applied to it. Regarding the integration projects, they require that development teams must be totally coordinated and that coordination tasks do not consume an excesive amount of time. In order to obtain the required results it’s necessary to have a couple of specific tools to minimize the efficiency losses in the constant but yet required cycles of development which makes developers waste time in repetitive tasks. The standards and open sources have been proved as an effective and powerful alternative which fulfills the requirements in which many large companies collaborate and actually have been reorienting their ways of understanding the business. In this interconected world, web services have a key role due to their versatility, a fact which gets even improved by the simplicity of use and interpretation of the web REST services. In this kind of projects there’s not only the need to coordinate team members but there’s an aditional need to establish the right way to operate between publishers and consumers of the RESTful API/Service. Keeping track of these services in a very detailed manner is a daunting task sometimes, it requires us to replicate parts of the development process and in general they (the services) are identical to the services of other projects. Not taking into account the latter could become a hassle and an obvious waste of time. The use of certain information or processes manually (repeating them but not considering them as instances) carries on with the risk of making huge mistakes. All of the above poses a question to the RESTful API/Services. How come something that’s been proven so useful, potent, powerful and versatile at the same time could be so ambiguous referring to its specification? Shouldn’t be there something available which regulates and coordinates publishers and consumers regarding how to interact with each other? Yes, there is and it’s precisely the main goal of this project