Resources for developing the API

[Nik Garkusha]

First, I think it's a fantastic project!

Second, can you share any links/resources that you leveraged in architecting your API? Any other APIs or similar efforts that you used as the basis for your API?

I'm curious as to the decisions on using JSON vs XML-based RESTful API, any considerations as the schema / taxonomy / etc. 

A few of us in OpenHalton / OpenHamilton are thinking through a process of architecting an API on municipal recreational activities to enable better search & integration with other apps. Designing the right schema and API that would apply across majority of scenarios seems to be one of the critical steps.

Lastly, the link [ BROWSE DATA ] pointing to https://raw.github.com/Open-Food/Open-Food-Standard/master/datasets is invalid. 

Nik

[Paolo Castagna]

On Mon, Mar 19, 2012 at 1:30 AM, Nik Garkusha <nikga...@gmail.com> wrote:
> Lastly, the link [ BROWSE DATA ] pointing
> to https://raw.github.com/Open-Food/Open-Food-Standard/master/datasets is
> invalid.

--> https://github.com/Open-Food/Open-Food-Standard/tree/master/datasets

[Chacha Sikes]

Hi Nik,

There are lots of ways to make APIs... In our case we based this on our experience interacting with API's so I can't point you to anything specific... there's so much. And technically, since there are so many ways to build them, people build them using whatever tools they have.

And there are different scales for publishing API's -- depending on usage, from hand-crafted API's hosted on heroku (like ours, which will suffice until the project grows) -- to using other hosted services  - like Freebase, or a data platform like buzzdata or kasabi -- or a platform to service the mass-market -- like Mashery or connecting with Google (ex. GTFS) or using Fusion tables.

There are some civic data people that are loosely talking about publishing civic data (similar to your recreation data) (we talked with google, 

JSON tends to be friendlier for developers... and in our case, for example, we are testing our API by integrating it with ongoing tech projects. For example, I have a database that I will cross-reference with the Open Food API by running a script in google refine, and then import my reconciled data into my project. It's just way easier to parse JSON objects programmatically. 

Also, I suspect that we lean towards JSON because it is just more compatible of a format with document databases -- and we plan to take full advantage of that format -- for example, in the future we could have zillions of attributes for food (mainly of crosswalks to other datasets - since that's sort of the hard part in this case of food, which has a proliferation of data.)

Hope this is helpful -- (and if I have mischaracterized anything, please chime in!!)

- Chach

@chachasikes

(p.s. Thanks for pointing out the bad link! The website is a volunteer effort that we work on in our free time.)

--
--
Open Food - http://open-food.org/
You received this message because you are subscribed to the Google
Groups "Open Food" group.
For more options, visit this group at
http://groups.google.com/group/open-food?hl=en

--
Chacha

[Nik Garkusha]

Thanks Chacha,

This is very helpful for a perspective. I guess I'm trying to wrap my head around the process for developing & implementing an API.

Is there a ‘proper’ approach for building an API: taxonomy –> schema –> specification –> ... –> API ?

With GTFS for example, you have a well-defined spec for sharing data, or a standard if you must. With some other projects like Open311 and Open 211 / Redirectory I'm seeing an emphasis on API vs defining schemas first. I guess it depends on the way you "visualize" the data and the complexity (or potential complexity) of relationships.

In case of open-food I suspect you may have zillions of attributes/Values & hence "relationships" you can't pre-define. However, looking at something like http://linkedrecipes.org/schema wondering if it makes sense to pre-define the schema/relationships up front. 

Maybe there's no "right" answer, but curious as to the thinking process behind this

Nik

On Monday, 19 March 2012 15:30:57 UTC-4, Chacha wrote:

Hi Nik,

There are lots of ways to make APIs... In our case we based this on our experience interacting with API's so I can't point you to anything specific... there's so much. And technically, since there are so many ways to build them, people build them using whatever tools they have.

And there are different scales for publishing API's -- depending on usage, from hand-crafted API's hosted on heroku (like ours, which will suffice until the project grows) -- to using other hosted services  - like Freebase, or a data platform like buzzdata or kasabi -- or a platform to service the mass-market -- like Mashery or connecting with Google (ex. GTFS) or using Fusion tables.

There are some civic data people that are loosely talking about publishing civic data (similar to your recreation data) (we talked with google, 

JSON tends to be friendlier for developers... and in our case, for example, we are testing our API by integrating it with ongoing tech projects. For example, I have a database that I will cross-reference with the Open Food API by running a script in google refine, and then import my reconciled data into my project. It's just way easier to parse JSON objects programmatically. 

Also, I suspect that we lean towards JSON because it is just more compatible of a format with document databases -- and we plan to take full advantage of that format -- for example, in the future we could have zillions of attributes for food (mainly of crosswalks to other datasets - since that's sort of the hard part in this case of food, which has a proliferation of data.)

Hope this is helpful -- (and if I have mischaracterized anything, please chime in!!)

- Chach

@chachasikes

(p.s. Thanks for pointing out the bad link! The website is a volunteer effort that we work on in our free time.)

Chacha

[Anthony Nicalo]

The linked recipe example is where we may end up one day. But building for that potential today doesn't exist yet. We don't even have an exhaustive list of whole (perishable) foods in english yet. We tried to build the API to support the current use case, maintain some flexibility and then we can iterate from here.