search

jesustorresdev / slack-badges-bot

2 stars 1 forks source link

Rutas desde la configuración #16

Closed mbdaso closed 5 years ago

mbdaso commented 5 years ago

Lo hice yo a mano, y se maneja con services.issuer http://vituin-chat.iaas.ull.es/api/issuer

Este es un caso que no necesita una entidad ni un servicio. No es algo propio del negocio de gestionar medillas. Es propio de la implementación de openbadges.

Se puede generar esa JSON con usa URL el adapto que da servicio al api openbadges porque es algo específico de esa API.

Ese adaptado / servicio web genera el JSON usando el nombre y descripción que lee de la configuación. Para las url se debe usar url_for() para genera la URL adecuada. Así el Issue se genera siempre bien aunque se cambie el dominio. No se deben usar URL hard-coded

Eso hace que me fije en algo. Las URL guardadas en JSON son absolutas. Debería ser los id de las entidades. Y el API del web service debe usar también esos id para identificar cosas. Solo deberá usarse una URL completa cuando se va a generar un JSON para OpenBadges. Y para esa URL se debe usar url_for()

Mirando al codigo veo que hemos mezclado dos cosas que debería estar separadas. Por una lado debería estar el API que usa el cliente de linea de comandos para gestionar el servicio. En este API el JSON puede ser parecido a las entidades que tenemos y es donde estan acciones como borrar, crear, etc.

Luego debería estar la interfaz que pide OpenBadges, que deberá ser otro web service. Sus JSON deben ser tal y como los indica el estándar. Y no debe permitir crear cosas ni asignada nada a nadie.

Creo que es algo que hablamos varias veces pero que esta separación se ido perdiendo segun avanza el proyecto. El tema es que es importante para separar el proyecto de un estándar concreto. Asi el servicio puede hablar con quienes entienden openbadges pero también quienes entienden otras cosas.

Originally posted by @aplatanado in https://github.com/aplatanado/slack-badges-bot/pull/14#issuecomment-522710878

El problema de usar url_for() es que habría que pasarle algo de la capa de infraestructura (app) a un servicio de la capa de aplicación (ConfigService), entonces habría una dependencia y se perdería la estructura.

Opino que es mejor hacerlo al revés, usar lo de ConfigService para poner las rutas en todos lados.

jesustorresdev commented 5 years ago

El problema de usar url_for() es que habría que pasarle algo de la capa de infraestructura (app) a un servicio de la capa de aplicación (ConfigService), entonces habría una dependencia y se perdería la estructura.

Opino que es mejor hacerlo al revés, usar lo de ConfigService para poner las rutas en todos lados.

No. A ver.

Esto configura la ruta en el WebService:

self.app.router.add_get('/badges/{badge_id}/{requested_data}', self.badge_handler, name='badges')

Y esto va en el utils/openbadge.py para obtener la URL:

app.route['badges'].url_for(badges_id=id, requested_data=<loquesea>)

En lugar de: self.config['BADGES_JSON_URL'].format(award.badge.id_str),

Así las URL se general tal y como el router las intercepta y despacha. Claro algunos programas permite cambiar la URL base. Por ejempo, tener en Config:

API_URI:'/api'

Y usar esa variable para configurar WebService para que escuche en /api.

Es más raro permitir configurar que /api/badges no sea /api/badges sino otra cosa y /api/awards tamién otra cosa. badges y award son los nombre de las entidades. No tiene sentido para una API poder cambiar eso. Pero la raíz de la ruta sí.