[Esip-discovery] Developing the "ESIP API"
Lynnes, Christopher S. (GSFC-6102)
christopher.s.lynnes at nasa.gov
Wed Jun 20 16:55:43 EDT 2012
On Jun 20, 2012, at 4:50 PM, Hua, Hook (388C) wrote:
> I think it depends on the goals of the ESIP Discovery and ESC clusters.
> An ESIP data API would be considered a software stack. It's been said that
> it is better to develop conventions/specifications/best practices over
> software stacks. The software stacks and APIs tie us down to an
> However, it be may good to promote the conventions/specifications/best
> practices instead, and by the way, provide reference implementations. This
> way, the community is more focused on the interface and not locked down to
> implementation. Program to interfaces and not to APIs as they say.
> Perhaps we are talking about the same thing where the ESIP data API is a
> reference implementation of existing specifications?
I think I am suggesting the same thing, more like a virtual API, i.e., one of packaging. The ESIP API would be the conventions and specs, but phrased/packaged in the form of an API (e.g., the EXO API). Also, examples, sample code, etc.
> Are we in the business of developing so
> On 6/20/12 12:21 PM, "Lynnes, Christopher S. (GSFC-6102)"
> <christopher.s.lynnes at nasa.gov> wrote:
>> At the OpenSource Summit here, looking at one of the winners of the NASA
>> Space Apps challenge called EXO API: http://exoapi.com/. It's a basic
>> API for searching and getting data, that's it. But the API is simple,
>> it's documented well, it's approachable.
>> What if we developed the ESIP data API? Based on casting + OpenSearch,
>> plus well-known formats/protocols, but all tied together in an API
>> document page, with a few examples?
>> Would this make sense? Worth the time?
>> Dr. Christopher Lynnes, NASA/GSFC, Code 610.2, 301-614-5185
>> Esip-discovery mailing list
>> Esip-discovery at lists.esipfed.org
Dr. Christopher Lynnes, NASA/GSFC, Code 610.2, 301-614-5185
More information about the Esip-discovery