search

Pixelrocket / ZAPP

ZAPP is een mobiele applicatie die (vertegenwoordigers van) cliënten van ZilliZ zorgboerderijen snel een eenvoudig toegang biedt tot actuele cliëntinformatie. Het betreft in eerste instantie het raadplegen van recente dagrapportages van eigen cliënten, het reageren op dagrapportages en toegang tot algemene informatie en contactinformatie.
http://www.pixelrocket.nl
4 stars 1 forks source link

Specificatie voor results vanuit webservices #13

Open marcelvanlangen opened 11 years ago

marcelvanlangen commented 11 years ago

Er zijn nu webservices beschikbaar, maar het is de vraag aan welke specificatie deze inhoudelijk dienen te voldoen. De basisspecificatie vanuit CF webservices is niet ideaal, ook niet als je serializeQueryByColumns als extra attribuut op TRUE zet.

Ideaal is het als de webservice de volgende specificatie heeft:

Het element DATA bevat in veel gevallen (in ieder geval in alle drie de gevallen waarvoor nu webservices beschikbaar zijn) het zogenaamde queryobject. Nadeel is echter dat SerializeJSON (zowel met als zonder serializeQueryByColumns), de aanwezige records niet handig organiseert. In het ideale geval is de data als volgt opgenomen (dit voorbeeld bevat 2 records van clienten):

{"clientid":207,"clientnameinformal":"Braaierd","clientnameformal":"Braaij, K. ","gender":1,"photo":"boefie.jpg"},{"clientid":195,"clientnameinformal":"Sem Verschuur","clientnameformal":"Verschuur, S.Q. ","gender":1,"photo":""}

We hebben al wel zojuist een stukje CF script gevonden die dit laatste oplevert, maar deze houdt nog geen rekening met de overige specificaties en is bovendien niet dynamisch. Dit stukje CF script ziet er (op basis van een query) als volgt uit:

var queryConvertedToArray = []; for( var i=1; i LTE qrySelect.recordcount; i++ ) { queryConvertedToArray[i] = {}; queryConvertedToArray[i]["clientid"] = qrySelect.clientid[i]; queryConvertedToArray[i]["clientnameinformal"] = qrySelect.clientnameinformal[i]; queryConvertedToArray[i]["clientnameformal"] = qrySelect.clientnameformal[i]; queryConvertedToArray[i]["photo"] = qrySelect.photo[i]; queryConvertedToArray[i]["gender"] = qrySelect.gender[i]; }
neoneo commented 11 years ago

Ok. De conversie van de query naar data heb ik gecommit. Ik lees deze mail net.

Technisch gezien is het het handigst om 1 entry point te hebben (de REST API cfc), en die roept de cfc's aan die het werk doen. Deze converteert dan het resultaat naar JSON. Geintegreerd hiermee moet ook iets gedaan worden met een sessie-token. Is er al iets dat de authenticatie regelt, dat we zo de API in kunnen schuiven? Als ik dat heb dan zorg ik wel dat die JSON eruit ziet zoals onder beschreven.

Op 13 mei 2013, om 19:36 heeft Marcel van Langen het volgende geschreven:

Er zijn nu webservices beschikbaar, maar het is de vraag aan welke specificatie deze inhoudelijk dienen te voldoen. De basisspecificatie vanuit CF webservices is niet ideaal, ook niet als je serializeQueryByColumns als extra attribuut op TRUE zet.

Ideaal is het als de webservice de volgende specificatie heeft:

iedere JSON resultset bestaat uit drie elementen: ROWCOUNT, RESULT en DATA het element ROWCOUNT bevat een numerieke waarde met het aantal records het element RESULT bevat een string met daarin de status (unauthorised etc.) het element DATA bevat de daadwerkelijke resultaten Het element DATA bevat in veel gevallen (in ieder geval in alle drie de gevallen waarvoor nu webservices beschikbaar zijn) het zogenaamde queryobject. Nadeel is echter dat SerializeJSON (zowel met als zonder serializeQueryByColumns), de aanwezige records niet handig organiseert. In het ideale geval is de data als volgt opgenomen (dit voorbeeld bevat 2 records van clienten):

{"clientid":207,"clientnameinformal":"Braaierd","clientnameformal":"Braaij, K. ","gender":1,"photo":"boefie.jpg"},{"clientid":195,"clientnameinformal":"Sem Verschuur","clientnameformal":"Verschuur, S.Q. ","gender":1,"photo":""}

We hebben al wel zojuist een stukje CF script gevonden die dit laatste oplevert, maar deze houdt nog geen rekening met de overige specificaties en is bovendien niet dynamisch. Dit stukje CF script ziet er (op basis van een query) als volgt uit:

var queryConvertedToArray = []; for( var i=1; i LTE qrySelect.recordcount; i++ ) { queryConvertedToArray[i] = {}; queryConvertedToArray[i]["clientid"] = qrySelect.clientid[i]; queryConvertedToArray[i]["clientnameinformal"] = qrySelect.clientnameinformal[i]; queryConvertedToArray[i]["clientnameformal"] = qrySelect.clientnameformal[i]; queryConvertedToArray[i]["photo"] = qrySelect.photo[i]; queryConvertedToArray[i]["gender"] = qrySelect.gender[i]; }

— Reply to this email directly or view it on GitHub.

marcelvanlangen commented 11 years ago

Helemaal goed! We hebben nog niets om sessies mee te identificeren. Ik heb op dit ogenblik ook eerlijk gezegd nog geen idee hoe we dit moeten gaan aanpakken. Ik neem aan dat we een sessietoken op het device gaan aanmaken op het moment dat de user succesvol een inlog heeft gedaan. Dit zal n.a.w. een combinatie zijn van zijn userid en zijn accountid. Die zijn er namelijk altijd. De database bevat echter ook in iedere tabel een UUID. Die kunnen we daarvoor ook inzetten. Het is wellicht een idee om deze combinatie bij ieder request te valideren. Hebben anderen hier al ideeën over?

wscherphof commented 11 years ago

Maarre... je hébt dit toch al, voor de website? Gewoon datzelfde gebruiken, hoor!

Ik neem aan dat het gaat middels en ? Dan krijgen we in Lua van CF een cookie header met de door CF zelf gegenereerde access tokens.

Wat wel anders moet dan bij de website, is dat je geen login webpagina kan gebruiken. Ik zou voorstellen om HTTP Basic Auth te nemen (zie http://help.adobe.com/en_US/ColdFusion/10.0/Developing/WSc3ff6d0ea77859461172e0811cbec0c8f9-7fe9.html); dat heb ik ook vanuit Lua al aan de praat :-)

Op 14 mei 2013 08:53 schreef Marcel van Langen notifications@github.comhet volgende:

Helemaal goed! We hebben nog niets om sessies mee te identificeren. Ik heb op dit ogenblik ook eerlijk gezegd nog geen idee hoe we dit moeten gaan aanpakken. Ik neem aan dat we een sessietoken op het device gaan aanmaken op het moment dat de user succesvol een inlog heeft gedaan. Dit zal n.a.w. een combinatie zijn van zijn userid en zijn accountid. Die zijn er namelijk altijd. De database bevat echter ook in iedere tabel een UUID. Die kunnen we daarvoor ook inzetten. Het is wellicht een idee om deze combinatie bij ieder request te valideren. Hebben anderen hier al ideeën over?

— Reply to this email directly or view it on GitHubhttps://github.com/Pixelrocket/ZAPP/issues/13#issuecomment-17859680 .

marcelvanlangen commented 11 years ago

Het is verdraaid lastig om hierop te reageren, omdat ik niet weet hoe een device daarmee om gaat. We gebruiken in Zilliz geen cflogin. We hebben nu voor ZAPP 3 webservices klaar staan. Eentje daarvan is de getCredentials. Deze post de username / password en krijgt vervolgens een ver-JSON-te query terug met daarin wat details van de user (naam, emailadres, accountid etc.). Dat is nu alles. Wat allemaal nog meer benodigd is, moeten we de volgende bijeenkomst bespreken.

wscherphof commented 11 years ago

OK, maar kan je misschien uitleggen hoe het in ZilliZ dan wel gaat? Dan kan ik nl. denk ik wel uitleggen hoe een device daarmee omgaat ;-)

Op 14 mei 2013 09:40 schreef Marcel van Langen notifications@github.comhet volgende:

Het is verdraaid lastig om hierop te reageren, omdat ik niet weet hoe een device daarmee om gaat. We gebruiken in Zilliz geen cflogin. We hebben nu voor ZAPP 3 webservices klaar staan. Eentje daarvan is de getCredentials. Deze post de username / password en krijgt vervolgens een ver-JSON-te query terug met daarin wat details van de user (naam, emailadres, accountid etc.). Dat is nu alles. Wat allemaal nog meer benodigd is, moeten we de volgende bijeenkomst bespreken.

— Reply to this email directly or view it on GitHubhttps://github.com/Pixelrocket/ZAPP/issues/13#issuecomment-17861201 .

marcelvanlangen commented 11 years ago

Ik denk echt dat het handiger is om het de volgende bijeenkomst te bespreken. Dan kunnen we kijken waar de beide werelden elkaar ontmoeten en wat we technisch gezien kunnen doen om die brug vervolgens te slaan. Voor nu volstaat het denk ik om te concluderen dat het voor het werken met de webservices nu volstaat dat ze JSON in het juiste formaat teruggeven. De sessie validatie zullen we dan op een later moment daaraan gaan toevoegen. Mee eens?

wscherphof commented 11 years ago

Okidoki. Via welke URL's zijn de services te bereiken?

marcelvanlangen commented 11 years ago

https://www.greenhillhost.nl/ws_zapp/getCredentials/ https://www.greenhillhost.nl/ws_zapp/getClients/ https://www.greenhillhost.nl/ws_zapp/getDailyReports/

Let wel op: deze URL's zijn nog de oudere versies, dus nog niet die al door Jeroen zijn aangepast (en nog niet voldoen aan de specs uit dit issue). Bovendien geeft getClients nu een iets ander formaat terug, omdat we daar gisteravond nog mee gestoeid hebben.