Posts Tagged ‘api’

Last week I spoke at RETech South and my first presentation was directed at Broker/Owners of real estate offices. After the session, I asked a trusted adviser to give me a harsh critique. They didn’t, but  they said something to the effect of, “I think you need to stop using acronyms that are comfortable for you, but foreign to your audience, like API.”

What they were referring to was a point in my talk where I advised the audience members to stop looking at the apps and tools put out by developers as an end unto themselves. Instead I wanted them to start asking the question, “how could I use the ‘ideas’ behind their tools to accomplish my specific goals? Does their API provide a path to use their tool in ways the creators would not have imagined?” As I write that now, I understand that I should have explained further.

So, let me explain further. First, API stands for “application programming interface.” It’s a way of explaining how different software applications communicate with each other. So, if you want your website or tool to interface with another website or tool, the API tells you how to do that and let’s you know what is and is not possible.

Now, the interesting thing about how most API documents are written is that, in many ways, even a non-programmer can get an idea of what’s possible. And this is why you, as a non-programming business person should care. Because if you know what’s possible, doors to new ideas and creative uses may open up for you. Here’s an example.

The Foursquare API

Much to my dismay, Foursquare doesn’t appear to be going away and among the current location-based social networks, it is the leader. But if I’m a business owner, in this case a real estate broker, I don’t want to just sit back and wait to see how the developers at Foursquare are going to move their platform forward. I want to take advantage of the network and make it work for me. First step, understand what it will let me have access to and make sure how I want to use the data is within the limits of their terms of service. The terms are simple enough to get to. Their terms of service are clearly displayed on their API page.

How can I tell what I have access to if I’m not a programmer?

I think most people will be surprised at how much “human-readable” text is contained in a well-done API document. Here’s a section of the Foursquare API that is under the category – “Check-in Methods.”

—

Checkins

Returns a list of recent checkins from friends.

If you pass in a geolat/geolong pair (optional, but recommended), we’ll send you back a <distance> inside each <checkin> object that you can use to sort your results.

Some notes on how to parse each <checkin> block:

• if <venue> exists, it’s a check-in to a proper place.
• if <venue> and <shout> exist, it’s a check-in to a proper place with a shout.
• if only <shout> exists, it’s a shout (no check-in). shouts are like callouts or tweets to your network. they need not be tied down to a particular place. it’s useful for sending messages like: “hey who’s up for hanging out later tonight?”.
• if no <venue> or <shout> exists, then it’s a silent check-in (“off-the-grid” as we like to say). this shows up in the timeline so that you know the person is out and about (to make it easy to meet up after they are done with whatever they are doing. it’s useful for stuff like dates, business meetings, etc).

URL: http://api.foursquare.com/v1/checkins
Formats: XML, JSON
HTTP Method(s): GET
Requires Authentication: Yes
Parameters:

• geolat – (optional, but recommended)
• geolong – (optional, but recommended)

—

Even if you’re not familiar with programming, you can learn several things from this section. A quality high school education is probably a good start, but I don’t need  to understand the formats, http methods or how to pass along the parameters to see that if I “pass in a geolat/geolong pair” that Foursquare is going to tell me how far away <distance> each place I can <checkin> is from my latitude and longitude. I know that my phone can figure out where I am and that a programmer can figure out how to get that information from my phone.

So, I now know that I can use the Foursquare API to deliver information about where I can check-in. In the next section of the API it tells me what I can do when I get that information. I can make a “shout” and send it out to my friends. I can check-in to one of the venues they send back. I can create a new venue and tell them about it. Just like I can do with the Foursquare app.

But this is where it gets cool. As long as I’m within the terms of service, I can then use that data to distribute information to places that the Foursquare app might not provide. Where might that be? Other websites? Other tools? I don’t know where it is for you, but you might. I know where that knowledge leads me. And armed with a better understanding of what’s possible, you may be spurred to create a new use for the tools, one that the developers never saw coming.

This is why the API is made public. This is where innovation lives. Diversity – of thought, experience, and need – provide the energy required for growth and change. It’s the beauty of an open system. And I believe that the missing ingredients in fueling commercial growth are the thoughts, experiences and needs of the average business owner responsible for making these tools work for their business.

So, do yourself a favor and take at look at the API of one of the tools you like using. Spend an hour studying it. Read past the programming jargon and sift through the text that feels like common English to see if it sparks some creative juices. I think you might be surprised.

And let me know how it goes.