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/57015f2b/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy