[Fiware-portals] API de notificaciones

[Francisco de la Vega]

Hola,

Las notificaciones quedarían como:

{
       "offering": {
                "organization": "owner_organization",
                "name": "offering_name",
                "version": "offering_version"
       },
        "reference": "referencia_de_compra",
        "customer": "actor_id",
        "applications": [{"id": 16,
                                "name": "app"},
                               {"id":20,
                                "name":"app2"}]
}

El campo customer contendria el actor_id tanto de un usuario como de una
organización.

Por otra parte ¿como quieres el token?, ahora mismo lo paso en la cabecera
Authentication: Bearer .token.

Saludos,
Francisco


El 5 de agosto de 2013 17:46, Antonio Tapiador del Dujo <
atapiador at dit.upm.es> escribió:

>  Hola Fancisco, también tienes lista el API de aplicaciones:
>
> https://github.com/ging/fi-ware-idm/wiki/API#applications
>
> El endpoint de compras en el IdM puede ser /purchases, ¿cómo queda el JSON
> al final?
>
> Un saludo.
>
>
> El 02/08/13 14:34, Antonio Tapiador del Dujo escribió:
>
> 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> 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> 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> 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
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>
> _______________________________________________
> Fiware-portals mailing listFiware-portals at lists.fi-ware.euhttps://lists.fi-ware.eu/listinfo/fiware-portals
>
>
>
> _______________________________________________
> Fiware-portals mailing list
> Fiware-portals at lists.fi-ware.eu
> https://lists.fi-ware.eu/listinfo/fiware-portals
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-portals/attachments/20130805/bb76abc1/attachment.html>