Documentación de la Api Rest del Backend de UMUApp.
El estándar usado para el intercambio de datos es JSON.
La URL base de los servicios es {entorno}/umuapp/rest/v1.0, teniendo {entorno} los siguientes valores según donde esté desplegada la aplicación:
Los servicios que ofrece el backend de UMUApp están securizados y requieren el uso de un sistema de autenticación para acceder a ellos.
El cliente UMUApp debe llamar en primera instancia al servicio de login del backend, enviando en la cabecera Authorization las credenciales que identifican al usuario frente al CAS (access_token, refresh_token y expires_in). Estas credenciales las obtuvo previamente UMUApp logueándose frente al CAS con el correo y la contraseña del usuario final.
Cuando el backend recibe la petición de login, autentica al usuario final frente al CAS usando las credenciales recibidas de UMUApp. Si la autenticación es correcta el CAS devuelve al backend los datos del usuario (DNI, nombre, apellidos, etc), y el backend a su vez los devuelve a UMUApp.
En este momento UMUApp puede conectar con cualquier servicio del backend pasándole únicamente el access_token que le pasó previamente en el login. Será responsabilidad del backend comprobar en cada petición la validez del token y encargarse de su renovación si fuera necesario.
Si el access_token recibido de UMUApp es válido, el backend se comunica con el servicio de la aplicación UM correspondiente para obtener los datos solicitados por UMUApp y devolvérselos en la respuesta.
El backend de UMUApp se comunica con las aplicaciones de los grupos de la UM (salvo con Aula Virtual) usando el mecanismo de autenticación definido por MNCS en las guías de Autenticación de servicios REST y Autenticación con token de la Wiki del programador de Ática.
A continuación se muestra un ejemplo completo del flujo de llamadas que se producen cuando UMUApp llama al servicio de obtener las alertas de un usuario.
1. UMUApp autentica al usuario final frente al CAS, el cual devuelve las credenciales que le identifican en su sistema.
UMUApp > CAS
POST https://entrada.um.es/cas/oauth2.0/accessToken
form-data: {username}, {password}
Documentación
2. UMUApp autentica al usuario frente al backend, pasando las credenciales recibidas en el paso 1. El backend almacena dichas credenciales y devuelve los datos personales que obtiene del CAS.
UMUApp > Backend
POST https://umuapp.um.es/umuapp/rest/v1.0/public/login
Authorization: {access_token}:{expires_in}:{refresh_token}
Backend > CAS
POST https://entrada.um.es/cas/oauth2.0/profile
query-param: {access_token}
Documentación
3. UMUApp llama al servicio de obtener alertas del backend, pasando el {access_token} que obtuvo en el paso 1.
UMUApp > Backend
GET https://umuapp.um.es//umuapp/rest/v1.0/private/cidu/notimovil/alertas/usuario
Authorization: {access_token}
4. Backend comprueba en su BD la existencia y validez del {access_token} que recibió de UMUApp en el paso 1.
Si el {access_token} válido, se loguea contra la aplicación Notimovil y obtiene las alertas del usuario:
Backend > Notimovil
POST https://notimovil/rest/v3.0/public/login
Authorization: {notimovil_login_token}
Documentación
Backend > Notimovil
GET https://notimovil/rest/v3.0/private/alertas/usuarios/{usuario}
Authorization: {notimovil_access_token}
Documentación
Si el {access_token} no es válido, llama al CAS para refrescarlo y guarda el nuevo valor en BD.
Backend > CAS
GET https://entrada.um.es/cas/oauth2.0/accessToken
form-data: {refresh_token}
Documentación
5. Backend devuelve a UMUApp las alertas del usuario.
HTTP/1.1 200 OK
[
{
"aplicacion": "SIVA",
"categoria": "General",
"personal": true,
"titulo": "Asignatura calificada",
"descripcion": "Ha obtenido en la asignatura 3551 TRAUMATOLOGÍA en la convocatoria de Junio del curso académico 2020/2021 la calificación de 10-Sobresaliente",
"estado": "LE",
"codigo_alerta": 788277,
"codigo_aplicacion": 3802,
"codigo_servicio_hijo": null,
"servicio_hijo": null,
"codigo_categoria": 0,
"fecha_creacion": "22/06/2021 13:53:27",
"fecha_envio": "22/06/2021 13:53:27",
"correo_emisor": null,
"referencia_web": null
},
...
]
...
Para la gestión de errores de la API se implementa una solución basada en la especificación RFC 7807 Problem Details for HTTP APIs. El mecanismo de manejo de errores se explica en detalle en la guía de Manejo de errores en servicios REST de la wiki del programador de Ática.
| nombre | ruta | métodos | descripción |
|---|---|---|---|
| ApiumServiceImpl |
|
|
|
| AsignaturaServiceImpl |
|
|
|
| CiduService |
|
|
|
| CurieServiceImpl |
|
|
|
| GestAcadServiceImpl |
|
|
|
| GestEconServiceImpl |
|
|
|
| PCIServiceImpl |
|
|
|
| PilotoServiceImpl |
|
|
|
| PresenciaServiceImpl |
|
|
|
| RRHHServiceImpl |
|
|
|
| SecurityServiceImpl |
|
|
|
| TelematicaServiceImpl |
|
|
|
| TestServiceImpl |
|
|