Extracting information from a webservice

[Aurélien PRALONG]

> May I ask you to tell me my ID? :)
> Unless, I am wrong, I think you missed something.

Oops, I thought the ID was unique for an email. My apologies.

By the way, when I registered, I got this error :
sqlalchemy.exc.IntegrityError

IntegrityError: (IntegrityError) column diver_confirmation_key is not
unique u'UPDATE divers SET diver_confirmation_key=? WHERE divers.diver = ?
AND divers.diver_creation_date = ?' ('ok', u'XXXXXXX', '2013-01-17')

I can give you my ID if that helps.

> I do not see an ID on the server side would help matching, could you
elaborate?
> I was more seeing a matching based on the date/time of the dives.

When you store a dive in DB, I suppose you have a row like this :

ID;Latitude;Longitude;date;hour;Name

The idea is to give ID (or another unique ID if you don't want to give SQL
ID) to clients. So they can associate it to the dive, and when another sync
is done, the matching is easy (just a string comparison).
> Which make me think, would we want a possibility to retrieve the dive
associated
> to someone for a given date or time period?

Good idea. A common (and easy) start would be to handle the "Last-Modified"
HTTP header (return all dives starting from client given date).

Speaking of dates, I wonder if we should merge "date" and "time" to one XML
datetime (e.g. 2013-01-17T22:12:10+01:
00) ? It would allow to add timezone information.

Aurélien


2013/1/18 Pierre-Yves Chibon <py at chibon.fr>

> On Thu, Jan 17, 2013 at 10:33:13PM +0100, Aurélien PRALONG wrote:
> >    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 ?
>
> May I ask you to tell me my ID? :)
>
> Unless, I am wrong, I think you missed something.
>
> >    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 do not see an ID on the server side would help matching, could you
> elaborate?
> I was more seeing a matching based on the date/time of the dives.
>
> Which make me think, would we want a possibility to retrieve the dive
> associated
> to someone for a given date or time period?
>
> Pierre
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130118/0ac685aa/attachment.html>