Hi Stephan; Great to hear you are getting some time to look at the server interactions.
1) What is the ID used in the JSON API and where is it comming from? In the documentation, the example for getPkg() uses 4143431. What is the meaning of this ID?
The "id" is used to correlate an invocation request with a response; the response is returned with the same "id" value as was sent out. This can be any value actually. In a synchronous usage it is not so useful, but has to be there anyway. In asynchronous usage it is obviously important. Keeping an incrementing counter with a lock on it to generate new numeric id values is a possible way to get unique id values.
2) I thought getPkg() is a general purpose informational API. However, fo the package I tested, it only tells the category, not other information like what screenshots are available for the package (I tested with "beam", for which I uploaded screenshots). Eventually, I think it would be good if there was only a single API invocation necessary per package to obtain all "further" information about that package. At the moment, that could be an array of all screenshot IDs, later it could also include an array with the user ratings. These should have two fields per rating: ID and language code.
I have not tackled user-ratings just yet. I could perhaps bring in screenshots and other detail into the "getPkg" method as _optional_ return data. It is a bit of balancing act of putting "too much" material into one API call when the client might not need it for its purpose. At the present time there is the opportunity to get this material in the "getPkgScreenshots()" method; given that presumably an HTTP socket is likely to remain open, is there any problem making further invocations to get further (finer) detail?
BTW; I am presently working on material around end-user driven localization of the package details.
Let me know how you get on! cheers. -- Andrew Lindesay