Actually, you can’t because you are outside the firewall. Trust me, if you were inside it’d be amazing. Check it out on GitHub for all the details!</div>

Here’s an example of an API in use. This one is made by our very own Dave Wilcox. It’s called Open Asset Fixer, or OAF for short.

You can try it out here.

phonelist.bvn.com.au:4567/S0910004/main/0/web_view That would get you the highest rated image from the S0910004 project, with the webview size. You can try it yourself by copying it into the address bar and noodling about with the values . The pattern is: <p style="padding-left: 30px;">phonelist.bvn.com.au:4567/:project_number/:tag/:index/:size size must be one of: squarethumbnail, small, web_view or medium. You can use this to get pictures of any project into a blog post on Tropos[17. You could use it from anywhere in the world, but the way our firewall and DNS is set up means that it is invisible from the outside world. If that wasn’t the case it would work because it is made of internet.]. This gets the highest rated image for that project from Open Asset for you to do something useful with. You can think of that as a way of plugging into a system, where Open Asset is the system. You could be plugging anything into it. In our case we plug the People + Projects system into it. There are lots of APIs out there. It’s virtually essential these days to have one if you want to be taken seriously! Interfaces are powerful, they give us control of systems. They allow people to do things. They also exert power, they control what things can be done and how these things can be done. We’re in one of those wild west situations with data and APIs. Whoever makes it across the prairie can open the data mine and control the data supply. We are collecting data and marshalling it into useful shapes. We need to decide what to do with it. Data kept in a box is worthless. Data wants to be socialised! If we are brave citizens of the 21^st century then we can make an interface that gives access to our data and controls who it gives access to. We can also set a precedent to our peers in the rest of the architecture world who are just about getting to grips with being brave citizens of the 20^th century! Part of the fun–and the challenge–of designing an API is that you have no idea what it will be used for. It could be for us to build our website[18. using your own software/systems is charmingly called dogfooding]. It could be a PhD researcher doing statistical analysis of Architectural firms over 50 years old. It could be a teacher explaining to 9-year-olds how to use APIs. It could even be ISIS collecting up images of Australian government buildings. I don’t mention that last one to undermine my argument, but to bring up the issue of paranoia. Someone always brings up a “what if… [insert bad thing here]… happens?” With APIs this issue is answered by what they are usually used for: making websites. If the data is OK to put on a website then it is OK to access it via the API. There are always worst case scenarios but if we were paralysed by caution on all of them then nothing would ever get done! <hr /> <div class="api-links">Learn how to use Apigee’s API to store your app data in the cloud!Learn how to use the WePay API!Learn how to use the YouTube API!Learn how to use the WePay API!Learn how to use the Box API!Learn OAuth2 with the GitHub APILearn how to use the SoundCloud API!Learn how to use the Mandrill API!Learn to use the NPR APILearn how to use the Dwolla API!Learn how to use the Evernote API!Learn how to use Python and the National Highway Traffic Safety Administration’s API!Learn how to use the Twitter API!Learn to use the SendGrid API</div> <hr />