stitching together APIs

Hi folks,
To frame the discussion for the October 11 conference call, I've started thinking about how to go about putting together a first draft of a standard API. It seems to me that it would be logical to simply blend the two APIs we currently have, NEWT and the iPlant API (Agave). There's a lot they have in common, though of course they have different terms for things. I would suggest we choose our terms based on three principles: 
coherence: terms in the API should have grammatical commonality with other terms of similar function in the API
clarity: terms should be unambiguous
memorability: terms should be easy to associate mentally with their meaning in the API
cross-center generalizability: terms should make sense in the context of any HPC center

We'll also need to discuss the scope of the standard API. How much should it cover? Clearly, centers should be free to do their own implementations; we are just defining a set of REST calls that can be re-used across implementations. But what functions should be left out of the standard? I'm thinking here of functions that are not specific to HPC. One example is the iPlant PostIt, which generates disposable URLs. I think that's a great service to offer people, but I would suggest we leave it out of a standard for HPC, since it isn't a function that arises from the HPC context. The iPlant Apps and Profile features strike me similarly. NEWT has a liststore feature that could also be seen as a non-HPC aspect of that API.

What do other people think? How should we define what is in/out of the spec?
-Annette
--
Annette Greiner
Outreach, Software, and Programming Group
NERSC, LBNL
amgreiner@lbl.gov
510-495-2935

Received on Tuesday, 2 October 2012 18:12:13 UTC