[Fiware-portals] API de notificaciones

[Antonio Tapiador del Dujo]

Estupendo, ya lo tienes tanto en el wiki como desplegado en producción

https://github.com/ging/fi-ware-idm/wiki/Using-the-deployed-instance

Por cierto, he aprovechado para cambiar el parámetro organization.name a 
organization.displayName siguiendo el esquema de grupos de SCIM que se 
ha acordado como API en el paquete de seguridad. Aún tengo la tarea 
pendiente de revisarlo en profundidad, por lo que es posible que haya 
algún que otro pequeño cambio. Os aviso.

Un saludo.

El 02/08/13 13:15, Francisco de la Vega escribió:
> OK, entonces creo que estaría bien pasar el actor_id como customer, de 
> hecho me vendría bien para gestionar otras cosas de los usuarios y 
> organizaciones en el Store.
>
>
> El 2 de agosto de 2013 13:10, Antonio Tapiador del Dujo 
> <atapiador at dit.upm.es <mailto:atapiador at dit.upm.es>> escribió:
>
>     Como veas, cambiar el API me supone escribir una línea más de
>     código, así que no es mucho problema. Lo que quede mejor.
>
>
>     El 02/08/13 13:09, Francisco de la Vega escribió:
>>     Creo que lo mas sencillo sería incluir un tipo (organización o
>>     usuario) e incluir su id. Lo del actor_id estaría bien pero te
>>     forzaría a cambiar la API para incluir ese valor en la respuesta.
>>
>>
>>     El 2 de agosto de 2013 13:03, Antonio Tapiador del Dujo
>>     <atapiador at dit.upm.es <mailto:atapiador at dit.upm.es>> escribió:
>>
>>         En el IdM el nombre de la organización no es único. Existen
>>         nicknames tanto para organizaciones como usuarios que son
>>         únicos pero no inmutables, es decir, tanto usuarios como
>>         organizaciones los pueden cambiar, aunque deben poner uno que
>>         no esté cogido. Lo que es único e inmutable son los ids,
>>         tanto por usuario como organización.
>>
>>         Los ids se pueden repetir entre distintos modelos. Es decir,
>>         hay organizacion 1 y usuario 1. Existe otro id en el idm, el
>>         id de actor, que sí es único para usuarios, organizaciones y
>>         aplicaciones. Es decir, si existe usuario con actor_id == 1
>>         no puede existir organizacion con actor_id == 1.
>>
>>         Usando nicknames ahora mismo podría existir condiciones de
>>         carrera, es decir, un usuario carga la página de una
>>         organización en la store, la organización cambia su nickname
>>         y posteriormente se realiza la compra.
>>
>>         Yo me quedaría más tranquilo si incluís un id por cliente,
>>         tal como 'organization-1' usando los ids de organizacion, o
>>         directamente el id de actor. ¿Qué te parece?
>>
>>
>>         El 02/08/13 12:52, Francisco de la Vega escribió:
>>>         Creo que en el caso del idM lo mejor es tener una URL única
>>>         a la que mandar las peticiones, por otra parte el customer
>>>         ahora mismo contiene el nickname del usuario o el nombre de
>>>         la organización dependiendo de como se haga la compra (En el
>>>         Store el nombre de una organización es único), si el nombre
>>>         de las organizaciones no es único en el idM podría incluir
>>>         un campo más con el identificador de la organización (estoy
>>>         suponiendo que se puede identificar un usuario por su nickname).
>>>
>>>         Saludos
>>>
>>>
>>>         El 2 de agosto de 2013 12:40, Antonio Tapiador del Dujo
>>>         <atapiador at dit.upm.es <mailto:atapiador at dit.upm.es>> escribió:
>>>
>>>             Estupendo Francisco, un par de dudas:
>>>
>>>             * ¿Manejamos la misma URL en el IdM para cada oferta, o
>>>             se necesita registrar una nueva URL por oferta?
>>>             * ¿customer es el nombre de la organización o usuario
>>>             cliente? Este nombre puede no ser único o cambiar ¿Se
>>>             podría pasar el id y/o tipo?
>>>
>>>             El 02/08/13 10:41, Francisco de la Vega escribió:
>>>
>>>                 Hola,
>>>
>>>                 Con respecto a la API de notificaciones, el Store
>>>                 manda una petición POST a la URL registrada al crear
>>>                 la oferta con un content type application/json y con
>>>                 el cuerpo:
>>>
>>>                 {
>>>                        "offering": {
>>>                                 "organization": "owner_organization",
>>>                                 "name": "offering_name",
>>>                                 "version": "offering_version"
>>>                        },
>>>                         "reference": "referencia_de_compra",
>>>                         "customer": "usuario_u_organización_cliente"
>>>                 }
>>>
>>>                 Entiendo que para la integración con el idM lo único
>>>                 que haría falta seria incluir un un campo
>>>                 conteniendo las aplicaciones compradas, algo como:
>>>
>>>                 POST
>>>                 Content-Type: application/json
>>>
>>>                 {
>>>                        "offering": {
>>>                                 "organization": "owner_organization",
>>>                                 "name": "offering_name",
>>>                                 "version": "offering_version"
>>>                        },
>>>                         "reference": "referencia_de_compra",
>>>                         "customer": "usuario_u_organización_cliente",
>>>                         "applications": [{"id": 16,
>>>                                                 "name": "app"},
>>>                                                {"id":20,
>>>                                                 "name":"app2"}]
>>>                 }
>>>
>>>                 Saludos,
>>>                 Francisco
>>>
>>>
>>>
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-portals/attachments/20130802/2621ef06/attachment.html>