[haiku-depot-web] Re: API getPkg()

  • From: Andrew Lindesay <apl@xxxxxxxxxxxxxx>
  • To: haiku-depot-web@xxxxxxxxxxxxx
  • Date: Tue, 08 Apr 2014 21:06:18 +1200

Hi Stephan;

Thanks for the example.

Hopefully the payload will be compressed with gzip so that somewhat mitigates waste in the payload. Oliver turned mod_gzip on a wee while ago so that should be in play now.

I don't see an inflexibility in the strongly typed request and response data types (DTOs). I can simply augment the DTO and the RPC will adapt the output. I have to change the server build to change the output anyway so loose typing in the DTOs also provides no additional flexibility.

My natural approach to the API would be to have "list" and "detail" targeted calls. However, I can do what you want with one "gotcha" and that gotcha is that the RPC does not "stream". One has to marshal the entire payload and then dispatch it. For this reason, I would have to put a size-limit on the response to protect the application server and then you would need to make a series of calls to get the packages' data to cache. Does that sound like it would get you what you want?

cheers.

On 8/04/14 8:44 pm, Stephan Aßmus wrote:
Am 08.04.2014 09:45, schrieb Andrew Lindesay:
Hi Stephan;

I think the API should be called along the lines of "getPkgInfo". And
besides the (average) rating, I also need the categories of each
package.
But why not make the API such that the client says which information to
include in the reply dynamically? Is this harder to do on the Java side?
It may be one of those times where declaring and annotating Java types
to be automatically transformed into JSON is getting in the way.

It would not be hard to do, but I don't see how declaring the return
data-structure for the resultant payload could constrain what I am doing
in any way *except* that transmission of bulk feeds of data are not
going to make any sense via an RPC mechanism because that's not
generally how an RPC mechanism works.

If you had envisioned a data feed of packages' data rather than an RPC
style API then let's try that.  If you were to supply a URL like this...

     http://.../feed/pkgs?since=123456&sshotmeta=true&;...

...that squirted out a feed (maybe RSS or ATOM), would that be more
amenable to what you are trying to work with?

I have not much of an idea of how RPC is usually used :-). All I see is
that I like the RPC API and that encoding the wanted packages in the URL
does not seem to scale. I don't want to use a time stamp, I already know
the complete package list that is valid for the specific Haiku
installation. And I know for which packages I have cached data. That
means I have a specific list of packages for which I want to query the
server. I also like the flexibility of an API which allows to extend
what information can be obtained with it, without changing the API itself.

As a result, I would stick to JSON and really just extend it in the
proposed ways. Here would be an example request (off the top of my head):

{
   "jsonrpc":"2.0",
   "id":4143431,
   "method":"getPkgInfo",
   "params":[{
     "names":[
       "apr","beam","curl","openssl","vision"
     ],
     "architectureCode":"x86",
     "data":[
       "RATING","CATEGORIES","SCREENSHOTS"
     ]
   }]
}

And the server could respond with:

{
   "jsonrpc":"2.0",
   "id":4143431,
   "results":[
     {
       "name":"apr",
       "rating":0,
       "categories":["SYSTEM"],
       "screenshots":[],
     },
     {
       "name":"beam",
       "rating":4.3,
       "categories":["INTERNETANDNETWORK"],
       "screenshots":[98769876,7654765],
     },
     {
       "name":"curl",
       "rating":0,
       "categories":["SYSTEM","INTERNETANDNETWORK"],
       "screenshots":[],
     },
     {
       "name":"openssl"
       "rating":0,
       "categories":["SYSTEM"],
       "screenshots":[],
     },
     {
       "name":"vision",
       "rating":5.0,
       "categories":["INTERNETANDNETWORK","PRODUCTIVITY"],
       "screenshots":[9870987,765476547,87658765],
     }
   ]
}

It could also be changed to not have redundant names, but I think it
would be less clear the the stream is already compressed, no?

Best regards,
-Stephan






--
Andrew Lindesay

Other related posts: