Extracting information from a webservice

[Pierre-Yves Chibon]

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