Sistema para la gestión del reconocimiento de equivalencias entre asignaturas: aplicación web

ESCUELA T´ ECNICA SUPERIOR DE INGENIER´ IA INFORM´ ATICA GRADO EN INGENIER´ IA INFORM´ ATICA Sistema para la gesti´on del reconocimiento de equivalencias entre asignaturas: aplicaci´on m´ovil System for managing the approval of equivalence between subjects: mobile application Autor: Nicol´as Vargas Ortega [email protected] Universidad de M´alaga Tutor: Jos´e del Campo ´ Avila [email protected] Universidad de M´alaga Co-tutor: M´onica Trella L´opez [email protected] Universidad de M´alaga Tutor coordinador: Jos´e del Campo ´ Avila UNIVERSIDAD DE M´ ALAGA M´alaga, Diciembre 2016 Fecha de defensa: El Secretario del Tribunal Resumen Las tareas administrativas referentes a los planes de movilidad estudiantil (p. ej. Erasmus, SICUE y ´ Unica), son un trabajo arduo y costoso que actualmente no se apoya en ninguna herramienta software. La aplicaci´on m´ovil del proyecto “Willyfog” intenta subsanar los problemas referentes a, las b´usquedas de equivalencias por parte de los estudiantes, la manera en la que reciben las notificaciones y las consultas del estado de sus peticiones. El conjunto de servicios de Willyfog, est´a formado por varias aplicaciones que conforman el proyecto completo, ´estas son: a) Willyfog-API, la interfaz de aplicaci´on que se comunica con la base de datos y realiza toda la l´ogica de negocio de las aplicaciones a las que sirve; b) Willyfog-OpenId, que gestiona la autenticaci´on de usuarios y maneja las sesiones; c) Willyfog-m´ovil, aplicaci´on m´ovil tratada en este TFG; d) Willyfog-Web, la aplicaci´on web que se encarga de poner a disposici´on los formularios a rellenar por los estudiantes y las tablas de equivalencias aceptadas por los profesores reconocedores y coordinadores de los centros, este ´ultimo apartado se desarrolla en otro TFG que se ha realizado de forma coordinada con este. Ofrecemos una arquitectura orientada a servicios la cual sirva como apoyo para futuras implementaciones en otras plataformas y tecnolog´ıas. Palabras clave Erasmus, SICUE, ´ Unica, equivalencias, aplicaci´on m´ovil, Android, OAuth2, OpenId Connect, MySQL, API, PHP, Java, SBT, Maven, Play framework, Slim framework 1 Abstract The administrative tasks concerning student mobility plans (e.g. Erasmus, SICUE and ´ Unica), are an intensive and expensive job that currently are not supported by any kind of software tool. The “Willyfog” mobile application attend to solve the problems of the equivalences searches by the students, the way that they can receive notifications and the status queries about their equivalence requests. The “Willyfog” ecosystem, not only consists of a mobile application, if not, are formed of various applications that make up the whole project, they are: a) Willyfog-API, an application interface that connect with the database and performs all the business logic of the applications it serves; b) WillyfogOpenId, that manages the user authentication and sessions; c) Willyfog-mobile, mobile application exposed here; d) Willyfog-Web, the web application that is responsible of the forms to be filled by students and the equivalence tables accepted by the recognizers professors and centre coordinators, this last point is developed in another TFG that has been done in a coordinated way with this. We offer a service-oriented architecture which serves as support for future implementations on other platforms and technologies. Keywords Erasmus, SICUE, ´ Unica, equivalences, mobile application, Android, OAuth2, OpenId Connect, MySQL, API, PHP, Java, SBT, Maven, Play framework, Slim framework 2 ´ Indice Resumen 1 Palabrasclave..................................... 1 Abstract 2 Keywords ....................................... 2 1. Introducci´on 5 1.1 Explicaci´on del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2 Estudiantes, profesores y coordinadores . . . . . . . . . . . . . . . . . . . . . 6 1.3 Flujo de trabajo para la petici´on de equivalencias . . . . . . . . . . . . . . . 7 1.4Objetivos ..................................... 8 1.5Estadodelarte .................................. 9 2. Requisitos 11 2.1RequisitosAPI .................................. 11 2.1.1Usuarios.................................. 11 2.1.2 Peticiones de equivalencia . . . . . . . . . . . . . . . . . . . . . . . . 12 2.1.3Asignaturas ................................ 12 2.1.4 Universidades y centros . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.1.5Pa´ısesyciudades ............................. 13 2.1.6Documentaci´on .............................. 13 2.1.7Notificaciones............................... 13 2.2 Requisitos aplicaci´on m´ovil . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2.1Perfildeusuario.............................. 14 2.2.2 Roles de la aplicaci´on m´ovil . . . . . . . . . . . . . . . . . . . . . . . 14 2.2.3 B´usqueda de equivalencias . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2.4 ´ Indicedepeticiones............................ 15 2.2.5 Sistema de notificaciones . . . . . . . . . . . . . . . . . . . . . . . . . 15 3. Dise˜no e Implementaci´on 17 3.1Arquitectura ................................... 17 3.1.1Basededatos............................... 18 3.1.2APIRESTful ............................... 23 3.1.3Aplicaci´onm´ovil ............................. 24 3.1.4OpenID .................................. 24 3.1.5 Integraci´on con servicio gravatar . . . . . . . . . . . . . . . . . . . . . 24 3.2Tecnolog´ıasusadas ................................ 24 3.2.1 Buscando las tecnolog´ıas . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.3 Dependencias del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.3.1 Dependencias de la API . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.3.2 Dependencias de la aplicaci´on m´ovil . . . . . . . . . . . . . . . . . . . 28 3.3.3 Dependencias del servidor OpenID . . . . . . . . . . . . . . . . . . . 28 3.4.Dise˜noAPI.................................... 28 3 3.4.1 ¿Por qu´e REST y no SOAP? . . . . . . . . . . . . . . . . . . . . . . . 29 3.4.2Versionado................................. 29 3.4.3Rutas ................................... 29 3.4.4 Protecci´on de la API con OAuth2 . . . . . . . . . . . . . . . . . . . . 30 3.5.Dise˜nom´ovil................................... 31 3.5.1MVC.................................... 31 3.5.2 Inicio de sesi´on OpenID . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.5.3 Dise˜no de la interfaz de usuario . . . . . . . . . . . . . . . . . . . . . 32 3.5.4 Integraci´on con la API . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.5.5 Integraci´on con OpenID . . . . . . . . . . . . . . . . . . . . . . . . . 34 4. Metodolog´ıas 37 4.1.Planificaci´on ................................... 37 4.2.Pruebas...................................... 37 4.3.Documentaci´on.................................. 38 4.3.1¿SwaggeroRAML?............................ 38 4.4.Entornodedesarrollo .............................. 39 4.4.1Vagrant .................................. 39 4.4.2Docker................................... 39 4.4.3 Desarrollo y Producci´on . . . . . . . . . . . . . . . . . . . . . . . . . 40 5. Conclusi´on 41 Referencias 43 A. Anexo 45 A.1Manualdeusuario................................ 45 A.2Manualdedespliegue .............................. 58 1.EntornoVagrant............................... 58 2.willyfog-api.................................. 58 3.willyfog-openid................................ 60 4.willyfog-web ................................. 60 5.willyfog-mobile................................ 60 6.Dominios ................................... 61 A.3ManualAPI ................................... 61 4 1. Introducci´on En la Universidad de M´alaga existen actualmente varios planes de movilidad estudiantil (Erasmus, SICUE, etc.) [1]. Cuando un estudiante solicita un plan de movilidad, necesita conocer qu´e asignaturas de la universidad de destino son equivalentes a las que tendr´ıa que cursar en su universidad de origen para, una vez superadas, poder recibir el reconocimiento correspondiente. Por tanto, es el estudiante el que se encarga de recopilar la informaci´on sobre el plan de estudios de la universidad destino para transmit´ırselo a su tutor acad´emico. A su vez, el tutor revisa la informaci´on y la facilita al coordinador del centro que elevar´a la solicitud a la comisi´on de reconocimiento. Aunque pueda parecer un proceso ´unico, var´ıa seg´un el centro de la universidad. En este proceso intervienen una serie de usuarios con diferentes roles cada uno. Todos estos usuarios siguen una estricta cadena de mando, que a su vez se puede extrapolar a una serie de fases que mantienen una prioridad. Esto significa que a lo largo del proceso, una petici´on puede llegar a ser rechazada antes de que llegue a manos del ´ultimo eslab´on. Adem´as, durante el curso del procedimiento no se dispone de herramientas espec´ıficas que lo simplifiquen. Son los problemas que intentamos solucionar con la creaci´on del sistema. Los estudiantes normalmente no est´an al tanto del estado de sus solicitudes, los profesores no tienen por qu´e avisar al estudiante. Si una solicitud es rechazada el estudiante podr´a verlo en las tablas de equivalencias que se publican peri´odicamente, si su petici´on no aparece se entiende que ha sido rechazada. En este caso el estudiante tendr´a que volver a enviar la petici´on cumpliendo los requisitos especificados por el coordinador o directamente su solicitud no es v´alida. Dado que el tel´efono m´ovil es una herramienta usada ampliamente entre la comunidad estudiantil, es ideal para que el estudiante est´e continuamente informado de como est´an sus solicitudes y pueda ser capaz de buscar entre toda la base de datos de equivalencias ya aceptadas por la comisi´on. Esto ahorrar´a mucho trabajo tanto a la parte de los estudiantes, como a la parte de los profesores. Aunque la aplicaci´on est´a pensada para cubrir las necesidades de la Universidad de M´alaga, se ha construido todo el conglomerado de herramientas pensando en dar servicio y soporte a m´as de una universidad, a m´as planes de movilidad y a todos los dispositivos, ya sean m´oviles, tablets, aplicaciones webs o incluso aplicaciones de escritorio, posibles. 1.1 Explicaci´on del problema Desde el inicio de una petici´on hasta que es resuelta, se ven involucrados varios procesos los cuales son, sin duda, manuales y bastante costosos. Actualmente, el alumno elige una (o varias) asignaturas las cuales cree que son equivalentes a las asignaturas de su grado de 5 Al crear un usuario se le asigna un grado (si es estudiante). Al crear un usuario se le asigna un centro al que pertenece. Un usuario al ser autenticado, se le asigna un token de acceso a la aplicaci´on. Debe de ofrecer un formulario de login a todos los clientes. Se puede intuir que tanto la API como el servidor OpenID se conectan a la misma base de datos, y se nutren de las mismas tablas. Hay otras formas de hacerlo pero, esto facilita bastante las cosas a la hora de desarrollar el m´odulo de autenticaci´on de la aplicaci´on y permite que s´olo en un sitio se creen los usuarios. La API lee de la tabla usuarios, y OpenID escribe en la tabla. 2.1.2 Peticiones de equivalencia Esta funcionalidad es el coraz´on de la API junto con los usuarios. Trata de realizar todas las funciones que una petici´on puede tener en el sistema, desde la creaci´on hasta comentar en una petici´on o notificar las actualizaciones de la misma. Las peticiones en el sistema deben cumplir: En el sistema las peticiones se diferencian por un estado, las pendientes y las cerradas. Una petici´on si se encuentra en el estado cerrada, puede ser porque haya sido rechazada o aceptada. Listar las peticiones, sea cual sea su estado. Listar las peticiones de un usuario en concreto. Las peticiones se pueden rechazar s´olo por profesores reconocedores o coordinadores. Las peticiones se pueden aceptar s´olo por profesores reconocedores o coordinadores. Comentar en las peticiones para posibles problemas o sugerencias. Listar todos los comentarios de una petici´on. Se pueden crear peticiones. S´olo los alumnos pueden crear peticiones. 2.1.3 Asignaturas La API debe de tener una ruta donde se puedan listar las asignaturas que hay en el sistema. Esta funci´on cubre los siguientes puntos: Listar todas las asignaturas que existen en el sistema. Buscar una asignatura por su identificador. Buscar las asignaturas equivalentes unas con otras. 12 Listar todas las asignaturas que hay de un grado en concreto. Una de las cosas importantes que realiza la API es el poder hacer una b´usqueda para encontrar las asignaturas que ya han sido reconocidas en el sistema. As´ı el estudiante antes de hacer una petici´on puede saber si las asignaturas que ya va a pedir han sido reconocidas, ahorrando as´ı trabajo a los profesores y coordinadores. 2.1.4 Universidades y centros Para realizar correctamente una petici´on de reconocimiento, el sistema tiene que poder ofrecer un listado completo de las universidades dadas de alta en el sistema y a qu´e centro pertenece. La funci´on de universidades y centros cumple los siguientes requisitos: Listar todas las universidades del sistema. Mostrar todos los centros de una universidad. Ver todos los grados pertenecientes a un centro. Sacar todos los profesores reconocedores de un centro. 2.1.5 Pa´ıses y ciudades Puesto que una universidad pertenece a una ciudad en concreto y necesita por ende un pa´ıs, se han creado unas cuantas funciones que nos permiten listar las ciudades y los pa´ıses que hay en el sistema. Este requisito es necesario para poder hacer las peticiones. 2.1.6 Documentaci´on Uno de los requisitos que la API cumple es el de la documentaci´on online. Para ello se necesita una ruta en la API que ofrezca a todo el usuario que lo solicite la documentaci´on de manera online para que se pueda consultar desde cualquier parte. 2.1.7 Notificaciones Las notificaciones en el sistema las maneja la API. Teniendo como requisitos principales: Se debe poder listar todas notificaciones de un usuario. Cuando un usuario ve sus notificaciones, ´estas se marcan como vistas. Las notificaciones s´olo se pueden ver si se recarga la aplicaci´on cliente (web o m´ovil). 13 2.2 Requisitos aplicaci´on m´ovil Dado que trabajar desde el m´ovil puede resultar inc´omodo, la idea principal de la aplicaci´on m´ovil es la de servir de punto informativo para los estudiantes. Un estudiante puede recibir en su m´ovil notificaciones de cu´ando una de sus peticiones se ha actualizado, saber en qu´e estado se encuentran sus peticiones y poder buscar r´apidamente en el sistema por equivalencias ya resueltas. 2.2.1 Perfil de usuario Una vez que un usuario se ha autenticado contra el servicio de OpenID y entra en la aplicaci´on m´ovil, lo primero que se encuentra es su perfil. ´ Este cumple las siguientes exigencias que se pidieron: Ver el nombre completo de un estudiantes. Saber la universidad a la que pertenece un estudiantes. Mostrar el grado en el un estudiante est´a dado de alta. Cambiar la foto de perfil de un usuario. El ´ultimo requisito que el perfil de usuario cumple en el m´ovil se hace a trav´es de un servicio externo a la API, llamado Gravatar [23]. Ya que el prop´osito de la API y de la aplicaci´on m´ovil no es el de tratar con im´agenes, hemos decidido optar por una soluci´on de terceros para subsanar esta carencia. 2.2.2 Roles de la aplicaci´on m´ovil Uno de los requisitos m´as expl´ıcitos y exigentes de la aplicaci´on m´ovil es el de que s´olo sea accesible para los estudiantes. Ya que ninguna de las funcionalidades que cubre la aplicaci´on m´ovil es la de trabajar con peticiones, si no, meramente informativa, el acceso se ha restringido a los estudiantes. El servidor OpenID autenticar´a a todos los usuarios que existan en el sistema, pero ser´a la aplicaci´on cliente (en esta caso m´ovil) la que se encargue de redireccionar a los usuarios que no tengan este rol hacia una vista vac´ıa donde se le indique que no pueden acceder a la aplicaci´on. 2.2.3 B´usqueda de equivalencias El principal pilar de la aplicaci´on m´ovil es el de poder ofrecer al usuario una b´usqueda de las asignaturas ya reconocidas en el sistema. Para ello se definieron los siguientes requisitos: Se debe poder buscar cualquier asignatura en el sistema ya reconocida. La b´usqueda se hace con cualquier tama˜no de palabra, es decir, con cualquier subcadena que empiece por la palabra que se quiera buscar. S´olo se debe mostrar el nombre de la asignatura de origen y la asignatura de destino. 14 2.2.4 ´ Indice de peticiones La aplicaci´on m´ovil cumple los siguientes requisitos en cuanto al ´ındice de peticiones que el usuario puede realizar: Ver sus peticiones pendientes. Seleccionar una petici´on pendiente y ver su informaci´on con m´as detalle. Poder ver sus peticiones cerradas. Si el usuario selecciona una petici´on cerrada del listado mostrado, debe poder ver la informaci´on detallada del estado de la misma. 2.2.5 Sistema de notificaciones Por ´ultimo, la aplicaci´on m´ovil cubre la exigencia de poder ver las notificaciones relacionadas con un usuario y sus peticiones. Los requisitos son: Se debe poder ver el listado de notificaciones de un usuario. Si un usuario no tiene ninguna notificaci´on se le informa con un mensaje y una lista vac´ıa. Un usuario tiene que entrar al men´u de notificaciones para poder ver si tiene notificaciones pendientes. 15 3. Dise˜no e Implementaci´on En general, Willyfog se basa en una arquitectura basada en servicios. La cual nos permite poder hacer actualizaciones del coraz´on del sistema (API) y que todos los clientes esten siempre a la ´ultima. Permite un desarrollo incremental y un modelo de negocio bastante configurable. 3.1 Arquitectura A continuaci´on se muestra la imagen de la arquitectura completa que conforma el proyecto. Aunque nosotros nos centraremos en la parte m´ovil y dejaremos a un lado la aplicaci´on web, podemos ver a simple vista todas las partes que componen Willyfog y c´omo est´an conectadas entre s´ı. Figura 2: Arquitectura de Willyfog Vamos a explicar un peque˜no caso de uso donde daremos unas pinceladas de c´omo se comporta la aplicaci´on y cu´al es el flujo de trabajo que un estudiante hace cuando accede a la aplicaci´on m´ovil. Empezando por el punto 1 de la Figura 2, podemos ver que el usuario tiene la posibilidad de acceder a la web (punto 3 de la Figura 2) o a la aplicaci´on m´ovil (punto 2 de la Figura 2) indistintamente. Esto realmente no es as´ı, s´olo los estudiantes pueden acceder a la aplicaci´on m´ovil y cualquier rol puede acceder a la aplicaci´on web. 17 Una vez que el estudiante decide acceder al m´ovil, el m´ovil lo primero que hace es ponerse en contacto con el servicio OpenID (punto 2.1 de la Figura 2) y pide la clave p´ublica, la clave p´ublica se necesita para descifrar el token que OpenID le devolver´a cuando el estudiante se autentique con toda la informaci´on del usuario. Ahora el usuario ser´a enviado a un web view donde tendr´a que rellenar un formulario servido por OpenID con su email y contrase˜na. Se autenticar´a y el m´ovil comenzar´a la comunicaci´on con la API (punto 2.2 de la Figura 2) de una manera segura. 3.1.1 Base de datos La base de datos fue el primer paso en el desarrollo de Willyfog. MySQL permite gestionar las bases de datos muy c´omodamente, as´ı que fue la opci´on elegida. En cuanto al dise˜no de la base de datos vamos a explicar un poco las principales entidades de nuestro modelo y a mostrar unas cuantas im´agenes para que se vean las relaciones entre s´ı. Puesto que la aplicaci´on m´ovil no tiene manera de gestionar la base de datos ya que, no existe un SGBD completo que sea capaz de correr con los recursos tan limitados del m´ovil, nace la necesidad de una interfaz de aplicaci´on que funcione como una capa que habla con la base de datos. Es por esto, que el dise˜no de la base de datos pertenece al ´ambito de la API. Se necesitan entidades para guardar tanto los pa´ıses, como las ciudades. Cada ciudad tiene una o m´as de una universidad y a su vez una universidad tiene uno o m´as centros donde se ofrecen uno o m´as grados. Todas estas entidades contienen un nombre y un c´odigo que las identifica, adem´as de un identificador num´erico ´unico que se utiliza de forma interna. Otra de las normas que hemos seguido a la hora de dise˜nar la base de datos es la de hacer tablas que contengan enumerados, por ejemplo, cuando detectamos que existe un enumerado en el sistema, lo registramos en una tabla, por ejemplo, los planes de movilidad. Este patr´on nos beneficia para que no puedan existir valores inconsistentes a la hora de hacer peticiones de equivalencias. Figura 3: Entidades que forman los grados Como podemos ver en la Figura 3, todas las entidades tienen un timestamp donde se guarda la hora en la que una fila fue creada, actualizada y borrada. Esto nos da mucha informaci´on a la hora de hacer auditor´ıas a la base de datos. Tambi´en todas las entidades 18 de nuestra base de datos tienen en com´un un identificador num´erico ´unico que se utiliza internamente por la API para acelerar el indexado. Una de las entidades m´as importantes de la base de datos es la entidad asignatura. Una asignatura tiene un c´odigo, un nombre y un n´umero de cr´editos y pertenece a un grado. Alrededor de esta entidad nacen otras relaciones con la entidad equivalencia y la entidad “asignaturas parecidas”. En la Figura 4 podemos ver estas relaciones m´as claramente: Figura 4: Entidades de equivalencia y asignaturas Para modelar que una asignatura es equivalente a otra, lo que tenemos es una relaci´on de muchos a muchos con la entidad equivalencia. Una equivalencia es la relaci´on que hay entre una asignatura A con una asignatura B que son reconocidas, donde puede existir una fecha de expiraci´on de manera opcional. En estas dos entidades es donde se centra toda la l´ogica de negocio a la hora de reconocer asignaturas en el sistema. 19 La siguiente entidad en la que nos vamos a centrar es en la petici´on. Una petici´on se registra en el sistema como una tabla que relaciona un estudiante, una asignatura de origen con una de destino y un tipo de movilidad. Otro patr´on que hemos usado en este punto ha sido el de separar en entidades diferentes tanto las peticiones aceptadas como rechazadas. Esta mejora hace que la l´ogica de negocio se simplifique much´ısimo, pudiendo, de un vistazo, ver las peticiones aceptadas y las rechazadas. En la Figura 5 podemos observar esta relaci´on. Figura 5: Entidades de peticiones Se puede ver claramente que lo ´unico que nos falta en el sistema son los usuarios y los roles. En la Figura 5 podemos ver que las entidades de peticiones aceptadas y rechazadas tienen una relaci´on con el profesor reconocedor. 20 La siguiente entidad es la encargada de guardar toda la informaci´on que un estudiante rellena en el formulario de equivalencias. Antes de mostrar como hemos modelado tanto los roles, como los usuarios, sus notificaciones y comentarios, vamos a comentar esta entidad, muy importante en el sistema. Para permitir que una asignatura sea equivalente a varias (con un m´aximo de 3) hemos creado una entidad que, con una relaci´on de muchos a muchos, relaciona una petici´on con una asignatura. La Figura 6 muestra esta relaci´on. Figura 6: Entidad de asignaturas por petici´on Como podemos ver en la Figura 6, de una petici´on de equivalencias de asignaturas se guardan los identificadores de la petici´on y de las asignaturas, el nombre de la asignatura, los cr´editos, el c´odigo de la asignatura, el pa´ıs, la ciudad, el centro y al grado al que pertenece esa asignatura y la URI o el path de los archivos que adjunta el estudiante. 21 Gson: De nuevo Google Inc. nos trae una de sus librer´ıa estrella. Aunque Play ya ofrece un serializador de JSON, elegimos esta librer´ıa por la facilidad que nos daba a la hora de parsear objetos java planos (POJOs) a JSON y viceversa. Sql2o: Ya que no quer´ıamos un ORM, por m´ultiples razones, buscamos una librer´ıa que fuera una fina capa de abstracci´on a la hora de mapear objetos java de las entidades de la base de datos. Sql2o[29] es una librer´ıa que escribiendo las consultas en MySQL, nos devuelve un objeto que podemos parsear con mucha facilidad a JSON gracias a la librer´ıa Gson. El hecho de no usar un ORM era porque ni quer´ıamos un query builder, ni porque nos interesaba la idea de cambiar de sistema gestor de base de datos. Un ORM nos iba a dar una latencia importante a la hora de hacer consultas a la base de datos desde java que no necesit´abamos. Simplemente con el mapeo nos bastaba. 3.3.2 Dependencias de la aplicaci´on m´ovil Las dependencias del m´ovil son bastante m´as reducidas que las de la API. Ya que s´olo necesit´abamos un cliente HTTP con el que hacer peticiones GET y POST c´omodamente, y serializar/deserializar mensajes JSON a objetos java. A continuaci´on las listamos: API Android: Aunque parezca mentira, la versi´on de la API usada en Android importa. La que se ha utilizado en este caso es la versi´on 21 de la API. Una de las cosas que nos ofrec´ıa esta versi´on era poder hacer un dise˜no material f´acilmente. Muchas de las opciones que esta versi´on de Android ofrece a la hora de construir las interfaces de usuario las anteriores no las tienen. Gson: Como librer´ıa para parser JSON a objetos. OkHttp: Una de las librer´ıas estrella de Android que nos da un cliente de HTTP completo y f´acil de usar. 3.3.3 Dependencias del servidor OpenID El servidor OpenID est´a construido por una librer´ıa bastante famosa de PHP, bshaffer [30] es el autor del servidor OAuth2, que entre otras muchas cosas tiene OpenID Connect implementado. Este autor es trabajador de Google Inc., una de las razones por lo que lo elegimos fue por la facilidad que nos daba la librer´ıa a la hora de poner en marcha un servidor de autenticaci´on con OpenID. 3.4. Dise˜no API Hemos hablado de la arquitectura de la API y de su dise˜no, pero ahora vamos a hablar de las decisiones en el dise˜no que han marcado la diferencia en todo el proyecto. 28 3.4.1 ¿Por qu´e REST y no SOAP? Cuando uno construye APIs tiene que decidir varias cosas antes de poder continuar. ¿Va a ser utilizada por m´as clientes?, en caso afirmativo, ¿C´omo va a ser protegida?, ¿Necesita mantener el estado?, ¿Qu´e tipo de mensajes intercambia?. Todas estas preguntas hacen decantarte por una arquitectura u otra. SOAP es un protocolo que funciona intercambiando mensajes XML, estos mensajes comunmente viajan a trav´es de HTTP aunque se puede utilizar cualquier otro protocolo de transporte. A diferencia de REST, SOAP define de una manera formal el tipo de mensajes que el servicio recibe mediante un archivo llamado WSDL, permite la autenticaci´on de usuarios mediante usuario y contrase˜na, y en general una forma m´as compacta de definir un servicio web. SOAP no fue elegido por el hecho de tener que definir el WSDL y tener que intercambiar mensajes XML. Sin embargo, REST nos permite trabajar con mensajes JSON, no tenemos que definir un archivo WSDL aunque existe algo parecido llamado WADL ya que, no tenemos que definir de manera formal ning´un contrato con nuestros clientes, y trabajamos a trav´es de POST, GET, PUT y DELETE, algo a lo que estamos acostumbrados a trabajar. Uno de los inconvenientes de REST es la dificultad a la hora de proteger de los recursos, que teniendo un protocolo como OAuth2 se soluciona f´acilmente, y que si este servicio tuviera que hacer streaming de datos no ser´ıa la mejor soluci´on. 3.4.2 Versionado Una de las partes importantes a la hora de dise˜nar la API es el versionado. Aunque parezca una mala pr´actica, mantener varias versiones del servicio web a veces es necesario, ya sea por el tipo de clientes que tengas, o porque quieras ir poco a poco migrando tu servicio de una versi´on a otra. La forma que hemos seguido a la hora de versionar la API es en las rutas de la misma. B´asicamente un cliente de nuestra API tiene que saber que las rutas que tiene son del estilo: http://www.example.com/api/v1/request Lo que hacemos es poner v1, v2, v3,... para diferenciar una versi´on de la otra. 3.4.3 Rutas Las rutas de la API se construyen de una forma muy similar al ejemplo anterior que hemos visto. Cuando se trata de una petici´on GET la ruta tiene que llevar en la URL los par´ametros necesarios para realizar la acci´on necesaria. En cuanto a las peticiones POST podemos tener ciertas variaciones en las rutas, por ejemplo, una ruta POST que necesita el identificador ´unico de una entidad de la base de datos pero tambi´en necesita un objeto 29 completo de una petici´on de equivalencia, lleva en la propia URL el identificador y en el cuerpo el objeto serializado a JSON de la petici´on en s´ı. Para las peticiones PUT, que las usamos a la hora de actualizar datos, seguimos el mismo criterio que las peticiones POST. El identificador en la URL y en el cuerpo el objeto completo que se quiere modificar. Para las peticiones DELETE lo mismo. 3.4.4 Protecci´on de la API con OAuth2 Para proteger la API hemos dise˜nado un flujo que nos permita autenticar a los usuarios. Debido a que REST no tiene ninguna forma de protegerse, tenemos que buscar otro tipo de soluciones, aqu´ı es donde entra OAuth2. OAuth2 es un protocolo para la protecci´on de APIs que nos ofrece restringir el uso de los recursos de nuestra API a cualquier nivel, mediante el uso de acceso por roles, nos permite, no tener que compartir las credenciales de acceso a los recursos protegidos con ninguna aplicaci´on cliente y lo m´as importante, todo este proceso va a trav´es del protocolo de transporte HTTP/s. Este tipo de acceso que damos a los clientes de nuestros recursos protegidos se hace mediantes access token, cadenas de texto arbitrario que representan la autorizaci´on del uso de esos recursos a un cliente en concreto. Normalmente este token se limita por un tiempo para evitar posibles problemas de seguridad, y se le provee al cliente con otro tipo de token llamado refresh token, otro tipo de token que permite al cliente volver a pedir otro token de acceso. Durante todo el documento hemos estado hablando sobre OpenID Connect, pero ahora estamos hablando sobre OAuth2. Realmente OpenID Connect es OAuth2 pero con algunas mejoras para poder dar token de acceso no s´olo a clientes (aplicaciones de terceros), si no, a usuarios finales con nombre de usuario y contrase˜na y permitir saber la informaci´on relacionada con un token de acceso y un usuario. Una de las cosas m´as importantes de OAuth2 son los scopes. Los scopes nos permiten restringir los recursos por niveles de acceso. Esto es interesante en nuestra arquitectura a la hora de poder dar acceso a unos recursos a los estudiantes y otro a los profesores por ejemplo. Los scopes se definen libremente y a nivel de aplicaci´on se le indica a los recursos que si el cliente que hace la petici´on no tiene el scope esperado, rechace la petici´on. Los tipos de acceso que se conceden en OAuth2 que nos son ´utiles son: 1. Client Credentials: B´asicamente este tipo de concesi´on de acceso es bastante simple. El cliente se autentica contra el servidor con sus credenciales (un identificador ´unico y una cadena de texto secreta) y el servidor al compobar que el cliente es leg´ıtimo, le entrega un token de acceso v´alido por un tiempo. Este tipo de autenticaci´on siempre se hace contra clientes que tienen un acceso privado y ´unico a nuestros recursos, es decir, estos clientes se han dado de alta en nuestro servidor OAuth2 de una 30 manera confidencial y privada por ejemplo, contactando con nosotros directamente. Este tipo de acceso en nuestro proyecto se usa a nivel de aplicaci´on para las acciones que requieren hacer peticiones a la API pero no tenemos ning´un usuario registrado, por ejemplo, en el formulario web de registro de nuevos usuarios. 2. Authorization code: Este tipo de concesi´on de acceso es la que usamos a nivel de usuario con OpenID Connect. El cliente pide al servidor de autenticaci´on un acceso, en el cuerpo de la petici´on env´ıa su identificador ´unico, su scope, un estado arbitrario (un c´odigo aleatorio para demostrar la autenticidad de la petici´on que el servidor entrega al cliente igual que se le env´ıo, as´ı evitamos redirecciones malintencionadas) y una URI que servir´a para redireccionar al usuario en caso afirmativo o negativo de autenticaci´on. Una vez que el servidor ha comprobado que el cliente es leg´ıtimo lo manda a la URI dada y le proporciona un token de autorizaci´on. El cliente usar´a este token contra el servicio de autorizaci´on del servidor y as´ı conseguir´a un token de acceso a los recursos protegidos. 3.5. Dise˜no m´ovil Anteriormente hemos hablado sobre el dise˜no m´ovil de manera general. Ahora vamos a explicar c´omo esta hecha la aplicaci´on m´ovil y qu´e patrones hemos seguido, hasta llegar a las especificaciones dadas. 3.5.1 MVC El patr´on de dise˜no que la aplicaci´on m´ovil ha que hemos seguido es el MVC. Es un patr´on cl´asico que nos permite que los controladores sean los que din´amicamente cambian las vistas y los modelos son simples POJOs que se parsean con los mensajes JSON que recibe de la API. Los controladores los hemos separado en las clases que acaban en “Content”, y en clases privadas dentro de las actividades principales de la aplicaci´on. Debido a que los Fragments son simplemente controladores que se limitan a sustituir el contenido de la actividad principal por el que corresponda. Para los modelos se ha seguido algo muy parecido a la API y en base a ella. En vez de dise˜nar los modelos, los modelos se definen directamente de los mensajes JSON que la API nos ofrece, de esta manera tenemos una manera directa de mapear las respuestas de la API a objetos Java y poder trabajar con ellos desde el m´ovil. Finalmente, las vistas las podemos separar en din´amicas y est´aticas. De hecho, s´olo hay una vista est´atica y las dem´as son todas din´amicas. La ´unica vista que es est´atica 31 es la principal, encargada de renderizar el men´u y la interfaz que el usuario siempre tiene disponible en todas partes de la aplicaci´on. Las vistas din´amicas se tratan desde las acciones del usuario, y son tablas y listas donde se renderizan cada vez que el usuario realiza una operaci´on en la aplicaci´on, por ejemplo, cuando pulsa en ver sus peticiones pendientes, o quiere ver sus notificaciones, en ese momento el fragment asociado a esa operaci´on se activa y cambia el contenido principal de la vista. 3.5.2 Inicio de sesi´on OpenID Lo primero que el usuario hace antes de entrar en la aplicaci´on es pulsar un bot´on de acceso a la aplicaci´on. Este b´oton har´a una petici´on as´ıncrona a la API, a una ruta desprotegida de la misma, que ofrece la clave p´ublica. Esta clave p´ublica es utilizada por el m´ovil para descifrar m´as adelante el mensaje JSON que la API ofrece con toda la informaci´on del usuario. Una vez pasada esta vista, el m´ovil pide al servicio OpenID un formulario de acceso con su Authorization code (ver secci´on 3.4.4). Este formulario de acceso autenticar´a al usuario y en caso afirmativo el usuario acceder´a a la aplicaci´on m´ovil a la secci´on de su perfil. Durante este ´ultimo paso, el WebView que el m´ovil genera para el renderizado del formulario web, se destruye de forma mientras que el servidor est´a trabajando y se muestra un mensaje de Loading... hasta que recibe la respuesta del servidor. 3.5.3 Dise˜no de la interfaz de usuario La interfaz de usuario se ha dise˜nado siguiendo el modelo que Google ofrece para dise˜nos material design[31]. Principalmente todo gira en torno al men´u, ´este est´a formado por una cabecera la cual muestra en la secci´on que el usuario se encuentra, a la derecha se da la opci´on de salir de la aplicaci´on y a la izquierda se encuentra el bot´on que despliega el men´u. 32 Figura 9: Pantalla de men´u Una vez que el usuario despliega el men´u en la cabecera del men´u desplegado se encuentra su nombre y una foto por defecto. A continuaci´on se listan las diferentes opciones que el men´u tiene: Peticiones pendientes: En este apartado se muestra una lista de todas las peticiones pendientes que tiene un estudiante. Si pulsa en alguna de la lista, podr´a ver los detalles de la misma. Habr´a un mensaje que indicar´a que la petici´on esta pendientes. Peticiones cerradas: Aqu´ı saldr´an las peticiones que han sido evaluadas por un profesor reconocedor. Este apartado tiene la misma similitud que el anterior, una lista donde aparecer´an las asignaturas con su c´odigo y si se pulsa en la deseada, se podr´an ver sus detalles. En este caso, se ha optado por otro tipo de dise˜no a la hora de mostrar al usuario si su petici´on ha sido aceptada o rechazada. Se muestra con un tono de transparente si la petici´on ha sido aceptada, en color verde y un check, o rechazada en color rojo y con una aspa. 33 Buscar: En este apartado primeramente se muestra un campo para rellenar la asignatura que se quiera buscar en el sistema. En caso de que una asignatura no haya sido encontrada, se mostrar´a un mensaje de que la asignatura no existe en el sistema. En el caso de que s´ı exista en el sistema, se mostrar´an todas las equivalencias que esa asignatura tiene, en forma de una lista. Mi perfil: En esta secci´on un estudiante puede ver su foto de perfil (si tuviera gravatar), su nombre y apellidos, su universidad y el grado en el que esta dado de alta. En esta secci´on se ha optado por un dise˜no material design. Notificaciones: Aqu´ı simplemente se muestran las notificaciones que el estudiante todav´ıa no ha le´ıdo. Se muestra en forma de lista y s´olo informa de que usuario ha comentado o ha hecho alguna acci´on en las peticiones del estudiante. 3.5.4 Integraci´on con la API En la integraci´on con la API, se han usado llamadas as´ıncronas de Android. Una de las cosas importantes que hay que tener en cuenta a la hora de desarrollar en Android es que el hilo principal de la aplicaci´on tiene que ser lo m´as estable posible, si por ejemplo se quiere hacer una petici´on a un servicio y que la aplicaci´on no quede congelada, se debe hacer de manera as´ıncrona. Por tanto, la integraci´on con la API se hace mediante peticiones as´ıncronas. Se tratan como clases privadas en cualquier lugar del proyecto Android donde tienen los siguientes m´etodos, onPreExecute(), doInBackground(), onPostExecute(). 1. onPreExecute(): Este m´etodo generalmente gestiona alguna tarea que se debe hacer antes de que la petici´on as´ıncrona se ejecute. En nuestro caso, se utiliza para mostrar dialogs al usuario para mostrar que la aplicaci´on est´a cargando. 2. doInBackground(): Esta acci´on es la petici´on as´ıncrona en s´ı. En nuestro caso, aqu´ı va la petici´on HTTP al servicio de nuestra API que corresponda, recibir´a el resultado y lo pasar´a al siguiente m´etodo. 3. onPostExecute(): Cuando la petici´on acaba, llega a este m´etodo el cual generalmente se utiliza para cerrar el dialog abierto en el m´etodo onPreExecute() y guardar la petici´on en la cach´e del m´ovil. Esto ahorra tiempo de respuesta de la aplicaci´on y hace que se pueda utilizar la informaci´on en cualquier lugar del m´ovil. No obstante, no todas las peticiones del m´ovil se cachean. 3.5.5 Integraci´on con OpenID La integraci´on con OpenID se hace de una manera similar a la de la API. Mediante una petici´on POST se autentica contra el servidor OpenID, mandando todos los datos necesarios, y la respuesta que se recibe se guarda en la cach´e del m´ovil. La actividad que maneja esta petici´on, es una de las principales de la aplicaci´on llamada OpenIdWebViewActivity. 34 En esta actividad se realizan varias operaciones. La primera es hacer la petici´on a la ruta que el servidor de autenticaci´on nos ofrece. En esta ruta se mandan los par´ametros por GET, es decir, en la propia URL. Se manda el identificador del cliente, la URI de redirecci´on, el tipo de respuesta que se quiere (en este caso un c´odigo de acceso), el scope una cadena siempre igual con el valor openid y el estado. La URL quedar´ıa: http://popokis.com:9000/authorize?client_id=<clientId>&redirect_uri=<redirectUri> &response_type=<responseType>&scope=<scope>&state=<state> Con todos estos datos, el servidor nos devuelve un formulario que el estudiante tendr´a que rellenar con sus datos, esto lo mostraremos por un WebView. Ahora s´olo falta que el usuario introduzca las credenciales de acceso. En este momento, cuando el usuario pulsa el bot´on de Authorize se hace un POST a la ruta del servidor OpenID que nos dar´a un token de acceso si todo marcha bien. En el cuerpo de esta petici´on POST pediremos al servidor que nos de acceso del tipo Authorization code, esto se especificar´a con una cadena de texto como clave grant type, se mandar´a el identificador del cliente, la clave secreta del cliente, el c´odigo y la URI de redireccionamiento. Si todo ha ido correcto, el servidor nos dar´a un token de acceso que durar´a por 24 horas, y que la aplicaci´on m´ovil guardar´a en la cach´e durante ese tiempo. Y para ahorrar tiempo, el m´ovil en este momento es cuando usar´a la clave p´ublica de la API para descifrar el JSON cifrado que el servidor de autenticaci´on nos ha devuelto con la informaci´on del usuario. As´ı podr´a ser guardada en cach´e y poder renderizar correctamente el perfil del usuario. 35 4. Metodolog´ıas 4.1. Planificaci´on En cuanto a la planificaci´on del proyecto se ha seguido la metodolog´ıa ´agil mediante Scrum. Se han utilizado sprints de dos semanas, los cuales los hemos ido enumerando con las letras del abecedario. En total han sido 5 sprints y medio. Una de las formas que hemos tenido de motivarnos en el trabajo, ha sido creando una nomenclatura espec´ıfica a la hora de ir tachando sprints en el calendario. Cuando est´as trabajando en un proyecto software, debes de tener todo perfectamente planificado, nosotros ten´ıamos un calendario el cual mostraba todos los sprints e ´ıbamos marc´andolos con una tri´angulo, un aspa y un c´ırculo respectivamente. El tri´angulo significaba que no hab´ıamos llegado a la planificaci´on de ese sprint, cosa que nos ha pasado s´olo una vez. El siguiente s´ımbolo es el de un aspa (representa la neutralidad), es muy t´ıpico ir tachando d´ıas en un calendario, as´ı ´ıbamos tachando algunos sprints en concreto 4 de ellos. Y por ´ultimo el c´ırculo, que representaba que un sprint hab´ıa ido tan bien que nos hab´ıa sobrado tiempo. Para la planificaci´on hemos usado pizarras de Scrum con la aplicaci´on Jira[32] de Atlassian. Esta aplicaci´on nos ha permitido llevar de una manera completa nuestro proyecto, asignar tareas y tiempos e ir haciendo un seguimiento bastante completo del desarrollo del proyecto. Jira permite la realizaci´on de informes en forma de gr´aficas para, de una manera visual, ver c´omo ha ido el ´ultimo sprint. Las pizarras que us´abamos conten´ıan cuatro secciones. La secci´on de ToDo donde se listaban todas las tareas previstas para ese sprint. La secci´on de In Progress donde se pon´ıan las tareas en las que se estaba trabajando en ello. La secci´on de Testing donde se dejaban las tareas hasta que se hac´ıan las pruebas necesarias. Y por ´ultimo, la secci´on de Done, donde se dejaban las tareas que hab´ıan completado el proceso de desarrollo y testeo. 4.2. Pruebas Las pruebas que se han realizado en el proyecto han sido de una forma un tanto especial. Al darnos cuenta de que TDD no era una posible metodolog´ıa ha seguir dado el tiempo y el desconocimiento en este ´ambito, se decidi´o dedicar los ´ultimos d´ıas de cada sprint (normalmente los dos ´ultimos d´ıas) ha realizar las pruebas a mano. El procedimiento era el siguiente: 1. Se desarrollaba una nueva funcionalidad. 2. Se dejaba en la pizarra Scrum, en la secci´on de Testing. 3. Llegado el d´ıa, se probaba la funcionalidad. 37 [23] Gravatar.https://en.gravatar.com/ [24] Plain Old Java Object.https://es.wikipedia.org/wiki/Plain_Old_Java_Object [25] Sistema gestor de dependencias Maven.https://maven.apache.org/ [26] Sistema gestor de dependencias SBT.http://www.scala-sbt.org/ [27] Netty server.http://netty.io/ [28] Guice.https://github.com/google/guice [29] Sql2o.https://github.com/aaberg/sql2o [30] Librer´ıa OAuth2.https://github.com/bshaffer/oauth2-server-php [31] Material design.https://material.google.com/#introduction-goals [32] Jira.https://es.atlassian.com/software/jira [33] Swagger.http://swagger.io/ [34] RAML.http://raml.org/ [35] Open API Initiative (OAI).https://www.openapis.org/ 44 A. Anexo A.1 Manual de usuario Antes de instalar la aplicaci´on m´ovil aseg´urese de que su m´ovil tiene la versi´on Android 5.1 o superior. Para poder instalar la aplicaci´on se debe pedir una apk al correo que se muestra a continuaci´on: nvorte[email protected]om, ya que la aplicaci´on no esta subida a ninguna tienda online y s´olo esta disponible su c´odigo fuente en www.github.com/ popokis, si se opta por bajar el c´odigo fuente se necesitar´a un IDE [5] para generar el archivo apk. Una vez instalada la aplicaci´on y acceda a ella por primera vez, encontrar´a la siguiente pantalla: Figura 10: Pantalla de bienvenida 45 Tendr´a que pulsar el bot´on ACCEDER y le enviar´a a la siguiente pantalla donde tendr´a que ingresar sus datos de acceso a la aplicaci´on. Si usted no est´a dado de alta, por favor, h´agalo a trav´es de la web que ofrecemos. Figura 11: Pantalla de login Pulse el bot´on Authorize para autenticarse y acceder a la aplicaci´on. Por favor, espere unos instantes mientras la aplicaci´on trabaja hasta llegar a la pantalla de su perfil de usuario. 46 Figura 12: Pantalla de perfil de usuario En la pantalla de perfil de usuario, podr´a ver su informaci´on general sobre su nombre, el grado en el que est´a dado de alta y la universidad a la que pertenece. Si esta informaci´on es err´onea, por favor, contacte con el administrador del sistema. Para poder cambiar la imagen de su perfil, debe de darse de alta una cuenta en el servicio gratuito gravatar. Si ya dispone de una cuenta en este servicio, por favor, omita este paso. 47 Figura 13: Pantalla de men´u En la Figura 13 se muestra el men´u que tiene disponible. Aqu´ı podr´a navegar por la aplicaci´on y poder aprovechar los servicios que ´esta le ofrece. Ahora vamos a ir listando los diferentes elementos del men´u y qu´e es lo que le ofrecen. 48 Figura 14: Pantalla general de peticiones pendientes En este apartado del men´u, se listan las peticiones que usted tiene pendiente de revisi´on por parte de la Comisi´on de Reconocimiento. A la izquierda se lista el c´odigo identificativo de la asignatura solicitada, y a la derecha el nombre de la misma. Si pulsa en una de la lista aparecer´a la pantalla de detalles de la petici´on (Figura 15). 49 Figura 15: Pantalla de detalles de petici´on En este apartado podr´a ver la informaci´on de su petici´on, el estado en el que se encuentra en la esquina superior derecha y la informaci´on resumida de la asignatura/as de destino que usted eligi´o en la petici´on. 50 Figura 16: Pantalla de peticiones cerradas Al igual que la secci´on de peticiones pendientes, en el apartado de peticiones cerradas podr´a ver las peticiones que ya han sido revisadas y cerradas por parte de la comisi´on. Si pulsa en una de las peticiones podr´a ver el estado en el que est´an, si han sido aceptadas o rechazadas (Figura 17 y Figura 18 respectivamente). 51 Figura 17: Pantalla de detalles de petici´on aceptada Las peticiones aceptadas ser´an marcadas con una imagen de check verde y se informar´a de su estado abajo de la pantalla. 52 Figura 18: Pantalla de detalles de petici´on rechazada Las peticiones rechazadas ser´an marcadas con una imagen de un aspa roja y se informar´a de su estado abajo de la pantalla. 53 3. willyfog-openid 1. Instalar las dependencias. $ cd ˜/ w i l l y f o g / p r o j e c t s / w il l yf o g −openid $ composer i n s t a l l 2. Establecer el archivo constants.php. Si no estas en producci´on, simplemente puedes renonmbrar el fichero constants.php.example aconstants.php: $ cp app/ constants . php . example app/ constants . php 3. Generar las claves p´ublicas y privadas: $ ope nssl genrsa −out data / privkey . pem 4096 $ ope nssl rsa −in data / privkey . pem −pubout −out data /pubkey . pem 4. willyfog-web 1. Instalar las dependencias. $ cd ˜/ w i l l y f o g / p r o j e c t s / w il l yf o g −web $ composer i n s t a l l 2. Establecer el archivo constants.php. Si no estas en producci´on, simplemente puedes renonmbrar el fichero constants.php.example aconstants.php: $ cp app/ constants . php . example app/ constants . php 3. Enlazar la clave p´ublica del servidor OpenID (para poder manejar los JWT): $ cd data $ ln −s . . / . . / w illy fog −openid / data /pubkey . pem 5. willyfog-mobile Dado que desplegar la aplicaci´on m´ovil para un usuario normal no es una tarea sencilla, se ha decidido que sea el usuario el que pida la aplicaci´on y recibir´a un APK firmado para que lo instale en su dispositivo. Teniendo en cuenta que esta aplicaci´on es libre y que no se va a lucrar nadie de ella, se permite la libre difusi´on de la misma. 60 6. Dominios Recuerda a˜nadir los distintos dominios al archivo /etc/hosts: $ echo ”1 92 .168.3 3. 10 w i l l y f o g . com api . w i l l y f o g . com openid . w i l l y f o g . com” |sudo tee −a / etc / hosts A.3 Manual API En cuanto al manual de la API, se encuentra disponible de forma online en la siguiente URL, http://popokis.github.io/willyfog-api/ Dado que hab´ıamos usado Swagger como herramienta para generar la documentaci´on, y poder poner a disposici´on de todo el mundo las posibles funcionalidades de la API, hemos querido que no este incrustada en esta memoria y pueda ser accesible desde cualquier dispositivo. Se ha puesto en una p´agina est´atica en la ra´ız del repositorio del proyecto Willyfog-API, as´ı adem´as de poder estar al alcance de cualquiera, tambi´en animamos a los usuarios a colaborar y hacer pull requests para ir mejorando la documentaci´on e ir ampli´andola. 61