Extracting information from a webservice

Aurélien PRALONG aurelien.pralong at gmail.com
Thu Jan 17 13:33:13 PST 2013


Hello all,

As you are writing about the companion, I will add some remarks.

I didn't see that Pierre did so many work on the web-service, so I did a
stub WS in java to start adding new features to the companion (such as
history and registering from the mobile app directly). I obtained quite the
same API, except from these points :
I used only one URI for dive parts:
   - GET /api/dive/{ID} to retrieve someone dives
   - PUT /api/dive/{ID} to add a dive (data is inside the HTTP content)
   - GET /api/user/{email} to get user ID from email
   - PUT /api/user/ to create a user (data is inside the HTTP content)

Content is passed as a XML. For instance, for a dive, we have :
<dive>
   <name>My dive</name>
   <latitude>10.0012</latitude>
   <longitude>3.1.5</longitude>
   <date>2013-01-17T22:12:10+01:00</date>
</dive>

The content in input is set via the "Content-Type" HTTP header (e.g.
application/xml or application/json), and the output by "Accept" header.

Although I understand it is easier to manipulate an URL, I personnaly think
this approach (the REST approach) is more clear (2 URI) and flexible.
Indeed, if we want to add pictures to a dive (which would be cool I think.
Always fun to add a blurry fish), we can simply add a field in the XML,
which would be more difficult in the URL (base64 in URL ?). And if use
Java/Spring it is realy fast to configure (but I dont' think you use it ;)
).

Another problem I see is security (I'm probably paranoid) : with the new
API, you just have to call the WS with an email (say, any email in the
mailing list), and you can get the ID, so upload and get dives. Maybe
should we consider to add a password, at least for ID recovery ?

For GPS sync, I would suggest that each dive returned by the WS (when
getting all list, or uploading one from companion) should have an ID
managed by the server, so that the matching is easy.

 I think I will work on the companion for Android soon, so if you have
feature requests, please let me know !

Aurélien


2013/1/17 Dirk Hohndel <dirk at hohndel.org>

>
> On Jan 17, 2013, at 10:42 AM, Lubomir I. Ivanov wrote:
>
> > also what is the idea in terms of UI here. i may have missed that...
> > user goes to a dialog where he can enter his details, presses
> > "download" and dives are downloaded from the webserice, which then are
> > added to the dive list?
> > presumably these dives are uploaded on there somehow, beforehand?
>
> The idea is that the web service (through the companion app) has GPS
> locations for many of your dives. I was assuming a workflow like this:
>
> User downloads dives from divecomputer
> Then opens the menu "Contact Subsurface Companion App Webservice" (catchy!)
> Enter credentials (you'll have those in an email) ((clearly only the first
> time - those need to go into the preferences…)
> Download XML file
> Hand it off to parse_xml which recognizes the header and applies much more
> generous rules to merging by time
> <<magic happens>>
> GPS data and location names have been added to dives.
>
> /D
> _______________________________________________
> subsurface mailing list
> subsurface at hohndel.org
> http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130117/47ab137c/attachment.html>


More information about the subsurface mailing list