RSS
 

Posts Tagged ‘APIs’

Introducing the Google APIs Explorer

07 Mar

Google is always looking for new ways to make it easier for developers to get started with our APIs. When you come across a new Google API, you often want to try it out without investing too much time. With that in mind, we are happy to announce the Google APIs Explorer, an interactive tool that lets you easily try out Google APIs right from your browser. Today, the Explorer supports over a half dozen APIs – and we expect that number to grow rapidly over the coming weeks and months.


By selecting an API you want to explore, you can see all the available methods and parameters along with inline documentation. Just fill out the parameters for the method you want to try and click “Execute”. The Explorer composes the request, executes it, and displays the response in real time. For some APIs that access private data you will need to “Switch to Private Access” and authorize the Explorer to do so.

To get you started, here are some sample requests; follow the links and press “Execute”:

The Explorer makes it easier for developers to discover what APIs we offer and get started using them within minutes. If you have any questions or comments, visit the help page or the support forum. We’d love to hear your feedback.

Happy exploring!


By Anton Lopyrev and Jason Hall, Google Developer Team
 
 

Crawl Bank Accounts with the Ghost of Wesabe

25 Feb

safehandle.jpgThe personal finance startup Wesabe may be dead, but its code lives on. Former team member Brian Donovan recently open sourced the framework used to connect with bank websites and download statements in a machine-readable form. This might not sound impressive, but with thousands of banks just in the U.S., all with different website setups, entire companies like Yodlee have been built around solving this problem.

By open sourcing the code, Wesabe makes it possible for hobbyists, researchers and starving startup founders to build new and innovative personal finance tools. The code itself is pretty bare bones; Brian admits he'd hoped to spruce it up before release but his new job didn't leave much time for a labor of love. What's crucial though is that it's a battle-tested system with broad coverage, and has a simple system for adding support for new institutions.

Sponsor

This makes it a strong potential competitor to Yodlee, if it can gather enough support from a community of developers to stay on top of the constantly changing bank websites. The forum posts ask for the code to be open sourced and now tips for running it show that there are enthusiasts interested in keeping it alive. This is a hopeful sign for innovation, but Yodlee may not be so happy. The loss of revenue from Mint after it was acquired by Intuit must have been painful for the company, and the emergence of an open-source alternative will be another headache.

So, what are the possibilities for end users? The simplest thing you can do with the code is set it up on your own machine and pull down all your own financial information automatically. Personal data lovers can create custom instrumentation for their own spending, saving and income patterns, building dashboards showing the measurements they care about. Getting a bit fancier, you could run something in the background on a private server. Want to send yourself an SMS when you approach your overdraft limit, or when there's an unusually large transaction? Having this "Automatic Uploader" code makes it easy to build your own system to handle those requirements.

Hopefully this will also inspire a new generation of startups to build personal finance tools. As founder Marc Hedlund says in his insight-packed post-mortem on Wesabe, in the financial world "the help consumers have is absolutely abysmal", so there are worlds of opportunity to create better solutions.

Photo by Todd Ehlers

Discuss

 
 

Why Every Brand Needs an Open API for Developers

04 Jan


Adam Kleinberg is co-founder and CEO at Traction, an interactive agency that aligns psychology with technology to create ideas that work. Catch him tweeting at @adamkleinberg and blogging at tractionco.com/blog.

The most effective ads today are experiences that provide value to customers. The biggest challenge is providing that value at scale in a world where people are empowered to consume media on their own terms through a dizzying array of gadgets, devices and doodads.

This puts marketers between a rock and a hard place.

For years, marketers have distributed messages to people with banner ads, which are like a rock that we throw at people with the dim hope that we’ll knock them upside the head. These rocks provide no value whatsoever.

Today, we’ve figured out how to create value — apps. Figuring out how to create utility is no easy path. Indeed, it is a “hard place” to reach.

But the reward is so great because with that app comes a deep and meaningful relationship with your customer — a new platform for your brand to foster long-term engagement with your target. And you are no dummy — you’ve even got a plan and a budget to drive downloads of your app. Bases are covered. What could go wrong?


We Already Have an App. What Could Go Wrong?


Application downloads look great in an ROI report, but when you take into account the proliferation of digital devices entering the market, the cost of producing unique brand experiences across all of them is exorbitant. You could spend a boatload of money creating and distributing this app only to have no one use it.

That’s what could go wrong.


Brand APIs as Value Platforms


Ironically, it is because of this proliferation of devices that the overall demand for content and utility is increasing. Brands should create value in the form of content and utility and distribute it via platforms that extend in reach beyond proprietary channels.

Apps are just channels. To establish value platforms, I propose that brands should consider creating their own APIs.

What is an API? An API, or application programming interface, is a hook. It’s one part of a software program that makes it easy for other programs to make use of a piece of its functionality or content. When APIs are made open, they can be accessed and used by anyone.

Facebook has APIs. Twitter has an API. Google has APIs out the wazoo. Why don’t brands have APIs? Well they should.

With APIs, you let other developers do your R&D for you. The benefit? You get development at scale with minimal investment. You effectively outsource risk because failures don’t cost you anything.

Brands need to think like startups. They must devise experiences that not only meet the demands of content and utility that audiences crave, but that are readily consumable in bite-sized chunks so that audiences can devour them on their own terms — and developers can serve them on theirs.

This last point is critical because it allows innovation to happen rapidly and without sustained investment.


“It Doesn’t Make Sense for My Brand”


kraft app image

“Not my brand,” you say. It’s easy to envision how brands whose core business revolves around technology or data could make use of an API. eBay has APIs that allow developers to access their database so they can create new and innovative ways to buy and sell merchandise. Netflix had more than 6,000 developers download its API to participate in its $1 million innovation competition. But what about the rest of us?

First, interfaces are becoming core to the fabric of more and more brands and products. Soon, you’ll have breakfast in the morning and there will be an interface on your refrigerator. You’ll hop in your car and there will be another interface. You drive to the airport, jump on a plane and voila… another interface. All of those interfaces are opportunities for brand APIs.

What if you sell macaroni and cheese? Kraft recently released a behemoth of an application for the iPad called Big Fork Little Fork that is filled with games, recipes and videos to help parents teach their kids about healthy eating and discover ways to do so using Kraft products. A worthy goal, but does it sell Kraft products? I downloaded it two months ago, but neither I nor my kids regularly use the app.

Imagine if Kraft released a simple API that allowed people to type in any ingredient and get back a list of healthy recipes from Kraft’s database? As new form factors emerge (like that refrigerator interface), independent developers could create new distribution mechanisms in a fraction of the time Kraft could — and without the cost.

What’s more, a company like Safeway could use that API to create its own app tied to their grocery delivery service. Customers could have all the ingredients in a selected recipe delivered to their front door. That would sell Kraft products.


APIs to Spread Utility


evian imageBrands could also create APIs to allow for the spread of utility. Here are some examples for major brands. Nike could create a “Just size it” API that allowed you to take a picture of your foot and find the perfect shoe size. How would they distribute it? Let their resellers figure that out. Evian could create a hydration API that calculated how much people really ought to drink each day and then reminded them to do so. Netflix created an API so developers could come up with better ways to make movie recommendations. Why couldn’t wine company Constellation Brands create an API so developers could come up with better ways to make wine recommendations?

Note that any of these ideas could make use of an app as a delivery mechanism for their API, but their underlying value comes first. By providing access to that value through an API, they would allow the delivery of that value to spread exponentially.

Sure, ideas aren’t always obvious or easy to come by. They never have been. That’s why some advertising works and some doesn’t. Today, ideas that actually work are even harder to devise. We must not only understand the psychology of why an idea will work, but how they will work. Rather than truly gaining an understanding of the latter, many marketers fall prey to a disease called “Shiny Object Syndrome.” They follow the pack and slip the latest shiny object into their marketing plans. Last year, it was a Facebook Page. This year, it’s an app.

Before you grab for that shiny object, ask yourself what you’re really trying to accomplish and how best to make that happen. The best answer may not be an app. It may be an API.


More Business Resources from Mashable:


- HOW TO: Get the Most Out of Facebook Insights for Small Business
- Why the Fashion Industry Is Betting Big on Branded Online Content
- Top 10 Digital Advertising Innovations of 2010
- 5 Predictions for the Public Relations Industry in 2011
- 7 Stellar Examples of Branded Content from the Fashion Industry

Image courtesy of iStockphoto, enot-poloskun


Reviews: Apps, Facebook, Google, Twitter, iStockphoto

More About: api, App, apps, brand, business, MARKETING, small business

For more Business coverage:

 
 

Google Just Lost a Potential Ally in its Legal Tussle with Oracle

12 Oct


The battle between Oracle and Google over Android’s use of Java just got a lot more interesting. That’s because IBM has announced that it will be collaborating with Oracle to work on the OpenJDK project.

This means that IBM will no longer be part of the Apache Software Foundation’s Project Harmony, the project that provides Android with the components it needs to run Java code. With IBM leaving the project, Harmony is basically dead in the water.

Although Android wasn’t mentioned in the announcement, this is all interrelated to the Oracle lawsuit. Google responded to the lawsuit last week, claiming that Oracle, which got Java out of its purchase of Sun Microsystems, was acting in bad faith.

For the non-Java savvy out there, here’s an abbreviated rundown of how and why all of this stuff matters:

Apache Harmony is an open source implementation of Java. The goal in creating the project was to unite all of the various free software Java implementations together under one banner.

The project had a lot of early support, the only problem was that Sun (and then Oracle) never offered the project with a Technology Compatibility Kit (TCK). The TCK is needed to prove that Harmony is compatible with the Java specification and can be seen as a certified Java independent version of Java. When Sun first open sourced aspects of Java in 2007, it said it would provide the Apache Foundation with the necessary TCK for certification.

Sun never made good on those assurances and when Oracle took over Sun, the new company wasn’t interested in sharing the TCKs, instead wanting to focus all of its efforts on the officially sanctioned open source Java implementation, OpenJDK.

IBM’s Bob Sutor discussed the decision on his blog, writing:

“We think this is the pragmatic choice. It became clear to us that first Sun and then Oracle were never planning to make the important test and certification tests for Java, the Java SE TCK, available to Apache. We disagreed with this choice, but it was not ours to make. So rather than continue to drive Harmony as an unofficial and uncertified Java effort, we decided to shift direction and put our efforts into OpenJDK. Our involvement will not be casual as we plan to hold leadership positions and, with the other members of the community, fully expect to have a strong say in how the project is managed and in which technical direction it goes.”

This is a big blow to the Harmony project and by extension, to the libraries and classes that Android implements from Harmony in Android. Without big backing like IBM behind the project, it’s not likely to survive.

For now, the Harmony implementation of Java is fine. The problem will be when future versions of Java are released and Harmony can’t keep up in terms of features.

In Java, staying compatible is key. Interestingly, InfoWorld notes that Google has more developers working on OpenJDK than Oracle. So why choose Harmony for Android?

We think it’s because Google wanted to do an end-run around Sun’s licensing requirements. In essence, getting to take advantage of Java SE on mobile devices (something that Sun explicitly forbade without a license), but not having to pay for it.

Long before Sun’s sale to Oracle, others pointed out the potential licensing and IP quagmire that Google was entering with Android. The reality was, Sun didn’t have the power, the funds or the industry clout to really do anything about it.

Oracle does. In fact, Oracle’s clout and power is underscored by IBM’s decision to join up. IBM may be making its decisions for pragmatic reasons, but in the decision shows that IBM is not willing to side with Google in this elongated fight.

At this point, Google’s only real recourse is to sensibly settle and pay Oracle, or countersue and drag the fight out even longer. By fighting back, Google risks alienating its Java-base of developers.

While we question how important having a strong base of Java developers really is to Android’s success in the long term, it doesn’t mean it’s worth risking the future developments of the platform on a legal gamble.

Oracle is out for blood and IBM just provided the syringe.


Reviews: Android, Google

More About: android, apache foundation, Google, harmony, IBM, java, lawsuits, legal, oracle

For more Tech coverage: