It’s been a week or so since I’ve worked on this project, and during a tutorial with Angus, he stressed that it was important to actually start making things.

I’ve never generated images with python before, and while i’ve worked quite a lot with SVGs, for now it seems to cumbersome to use to start drafting ideas, so instead i’ve decided to work with Processing. It’s really fantastic for generating quick ideas, and it’s so incredibly visual. Previously, I tampered with the idea of using WebGL, but in my time frame I think it would be too unrealistic to learn a whole new system.

In order to get my database data to work with in Processing, I decided to release an API. This is because although I have a copy of the database on my local server, I want this to be able to work anywhere, especially in consideration of those marking the piece. If the final piece is in Processing, it will need to work on anyone’s machine, and luckily Processing applications are easy to generate for each operating system, so including the data is the only hurdle. Also, I want the piece to work in real time with real data that is being submitted to my database.

I have been referring to Miguel Grinberg’s tutorials on Flask, and luckily he has written documentation to support this. I didn’t realise just how simple it was to implement this on my own server.

For now, I only want to be getting information, not posting it, although this is an idea for the future. So I have kind of avoided cookies and authentication, nothing is really of importance on my server and time is of the essence.

I believe very much in the open source movement and feel that alongside releasing my code, releasing an API is a step in the right direction. The whole learning experience of understanding programming and web practises has relied on open source code, tutorials and documentation, as well as APIs. As a maker myself, I have used many of these, especially with Yummly for this project. Yes, I am releasing information I obtained from Yummly, however this API will not directly affect the Yummly website or invoke any amount of calls to it, and I will declare that the original information is derived from Yummly data. Also, many leading organisations have released API’s, Instagram, Last.fm and The Weather Channel to name a few – this is becoming more common, so in a way I am keeping up with industry. I can already think of how I can implement this on projects in my work life!

Firstly, I created a new blueprint within my Flask application on my server. Getting information is as simple as serialising the data to JSON and creating an URL to access it – that’s it! Who knew.

Using some of Miguel’s examples as a basis, I adapted these for my own use to gather Recipe, Flavour and Ingredient data. I created the functionality so that the REST URLs for the flavours and ingredients is accessible through the recipe API request, and vice versa.

The implementation of this at the views level can be seen here and the database/model view here.

Each result will look a little like this.

Screen Shot 2015-05-27 at 21.44.08
Screen Shot 2015-05-27 at 21.48.56
Screen Shot 2015-05-27 at 21.49.29

I feel very happy with this, I actually punched the air in victory that this was possible and I managed to do it myself without tearing my hair out. With the API in mind, i’m going to look at some descriptions of wine, just to make sure that words aren’t enough.

If you would like to have a go, all of my recipes (all 48 of them) are viewable through this url:
http://ginfographic.chez.io/api/v1.0/recipes/1
Just change the number at the end of the URL.