Monthly Archives

Web API Sites

January 8th, 2008

Google, Facebook Join DataPortability.org

In a promising sign for the future of data portability across platforms, earlier today DataPortability.org Workgroup announced that representatives from Google, Facebook, and Plaxo joined their initative: “We are proud to announce the inclusion of Joseph Smarr (Plaxo), Brad Fitzpatrick (Google) and Benjamin Ling (Facebook) to the DataPortability Workgroup.” For more on the group’s goals, which includes creating a ‘DataPortability Reference Design’, see their philosophy and mission:

Our Philosophy: As users, our identity, photos, videos and other forms of personal data should be discoverable by, and shared between our chosen tools or vendors. We need a DHCP for Identity. A distributed File System for data. The technologies already exist, we simply need a complete reference design to put the pieces together.

Our Mission: To put all existing technologies and initiatives in context to create a reference design for end-to-end Data Portability. And, to promote that design to the developer, vendor and end-user community.

From a technology perspective, they encourage an “Invent Nothing” approach that builds on existing standards like:

Involvement from some of the biggest names in the business means greater potential for real progress on interoperability. For more on this story see ReadWriteWeb and TechMeme.

Share This

Posted by John Musser as BestPractices, Issues, OpenSocial, Social at 11:59 AM | 3 Comments »

October 16th, 2007

Successful Developer Programs

There were a number of interesting sessions at yesterday’s Business of APIs Conference hosted by Mashery. Dave McClure, who previously oversaw the launch of the PayPal developer network, gave an engaging, to-the-point talk entitled “Successful Developer Programs”. If you’re running an API developer network or even thinking of running one, here’s a summary of good ideas and important questions to ask yourself:

Read the rest of “Successful Developer Programs” »

Share This

Posted by John Musser as BestPractices, Events, Featured, Money, Popular at 7:17 PM | 1 Comment »

June 25th, 2007

eBay Tops Web 2.0 Developer Survey

eBay topped five other leading Web 2.0 developer programs including Yahoo, Amazon, Google, PayPal, and Microsoft in a study published this month by Evans Data Corporation. The 34 page report entitled “Developer’s Choice: Web 2.0 Developer Programs” is based on a recent survey of 400 developers and is available at the EDC site, free registration required. For readers interested in this space it’s a worthwhile read. Some highlights:

Developers were asked about a range of factors including API functionality, developer support, documentation, certification, marketing assistance, security, downtime, solutions directories and tools.
The best overall rating went to eBay followed by Yahoo, Microsoft, Google, Amazon and PayPal respectively.
Even within a single provider’s program there was a wide range of satisfaction. For example Yahoo and Microsoft scored well in forums and blogs while PayPal and Amazon rated lower on these.
The financial benefits a program offers makes a big difference with eBay and Amazon scoring well here.

Here’s a quick overview of the strengths and weaknesses by vendor:

PayPal: Scored highest on security but did not fare well on forums and developer community.
Amazon: Scored highly on financial benefits but respondents gave Amazon lower marks on documentation and outages, which EDC notes is surprising and indeed may be a symptom of expectations more than anything else.
eBay: Had the most problems with outages and downtime as well as integration difficulty. They scored highly on financial benefits, support and documentation. Their APIs were voted best of the group.
Google: Rates well for ease of integration, good uptime, and tools. Google scored lower on financial benefit and in the middle on many of the metrics.
Yahoo: Scored highest in terms of ongoing communication and reasonably well on their APIs and their community services like forums. Yahoo is seen less highly in terms of helping developers make money.
Microsoft: Scored well on their developer community programs and tools but not so well on integration, direct financial benefit or marketing assistance.

Share This

Posted by John Musser as BestPractices, Issues, ebay at 12:48 AM | 1 Comment »

April 9th, 2007

Mashup Case Study: MyPunchbowl

If you want to learn more about the real story behind mashups, APIs and tools — the good, bad and the ugly — you’re in luck. Today we’re introducing a new feature on the site: the ProgrammableWeb Case Studies. In this ongoing series we’ll be going behind the scenes of the programmable web by talking with mashup developers, API providers, tool vendors, and other notable players in this ecosystem.

Over time this collected knowledgebase of experience can hopefully help us all get a better understanding of who’s doing what, what’s working, what are the viable business models, what are the technology tips-and-tricks, and finally, we might pick-up some good anecdotes along the way.

Our first interview is with Matt Douglas, CEO of MyPunchbowl, a Boston-based startup focused on event and party planning. As part of their service they integrate a variety of third-party APIs for things ranging from mapping to contacts to media management.

1. What is MyPunchbowl and why did you start the company?

MyPunchbowl.com is a new web application for event and party planning. It features an easy to use interface and tools for every step in the lifecycle of a party. We built MyPunchbowl because we didn’t like the current products on the market, and we had a vision for a product that would help a user with every step of party planning. Fundamentally, we built the product for us. And we hope our customers love it too.

2. What APIs did you use and what were the best and the worst aspects of using them?

We use a handful of API’s right now including Google Maps, Flickr, YouTube, and the Plaxo Address Book Widget. We’ve had a lot of success extending our product by utilizing these API’s. What we’ve found, however, is a significant difference in dealing with the companies behind these API’s. Plaxo was great; they were responsive to our needs, and their support forum is very useful. Some of the other companies weren’t as helpful. In one case, we had a question about terms of use, and it took a lot longer than you would think (weeks!) to get a clear answer. We plan to continue to expand our product through the use of API’s. For a startup like ours, it’s a great way to implement a lot of functionality in a short amount of time.

3. What programming languages and tools is this built with?

MyPunchbowl.com is a Ruby on Rails application. The site is built on Prototype/Script.aculo.us, with a MySQL database. I’d be remiss if I didn’t also mention our awesome bug tracking system– we use a product called Squish that serves our needs very well.

4. What is your business model?

MyPunchbowl.com has a large revenue opportunity. Our business is based on a number of different revenue sources including targeted advertising, revenue sharing on supplies and merchandise, and affiliate revenue through booking partners. In addition, we believe our core software is an attractive package to license to key brands in the event and party industry.

5. Can you tell us about any metrics for this application: traffic, revenue or other?

We’ve had a very successful launch thanks to mentions on such great sites as ProgrammableWeb. For us, the key has been an aggressive PR strategy, that has paid dividends in traffic and users.

6. What are the near-term and longer-term plans for this project?

We’re working on making MyPunchbowl.com the best event and party planning application on the web. We’re fortunate that we have very vocal and passionate users. They’ve been very clear about which features are the most important. In the long-term, we think we have some unique ideas which will change the way people plan parties. We also have some creative ideas about how to make the product more collaborative. Look for us to also find unique channels and strategic partners as we grow the business.

7. Do you foresee using other APIs as part of your service in the future?

Oh yes, definitely. We think using API’s has a couple of distinct advantages. First, it helps us accelerate our product development. Second, users like the ability to leverage their content. For example, the Plaxo Address Book widget is an example of a feature which allows users to quickly import their address book into MyPunchbowl. We don’t have an address book feature in MyPunchbowl, because we personally don’t like having to maintain more than one address book. Using the Plaxo API gives us the ability to bring the content of an address book in easily, regardless of where you maintain your addresses.

8. Using third-party APIs is seen by many as introducing business and technology risk. How do view this issue and how do you account for it in your strategy and implementation?

This is something we’ve talked about a lot, and the good news is that there are new libraries coming out that allow you to “cascade” API’s. For example, we use Yahoo geocoding, but what if Yahoo goes down? We think the best thing to do is to implement a library that will immediately go to Google geocoding (or any of the others) if the one fails. We think this is a great way to mitigate our risk and there are lots of great libraries for Ruby on Rails to do these kinds of things like the plug-in for Rails called “acts_as_geocodable”.

9. From an API and mashup perspective, what are the main lessons learned from this project and/or is there any advice you’d like to share on the development, design or business side of mashups?

The key is to test, test, test. For us, we have spent a lot of time making sure that our implementation is bullet-proof in all of the various browsers. We’ve had lots of stumbling blocks along the way– for example, Google maps are pretty finicky in IE. We think it is important to treat the API features as if they were our own. After all, our customers are the ones who are interacting with the functionality. Test, test, test. And when you are done, test some more.

10. Are there any mashup-related APIs, tools or services that don’t exist today that you’d like to see? (Or, what API would you kill for?)

We really wish that there were some more standards out there for API’s. For example, wouldn’t it be great if there were a standard creative commons API for all images on the web? That way, we could do a single search rather than pulling from all of the various photo sharing sites. As video grows online, this is going to be an issue too. Right now, we integrate with YouTube, but there are many others out there. API’s are great, but it does take significant resources when we have to implement the API for one service at a time.

And finally, besides your own, do you have a favorite mashup?

I’m still partial to HousingMaps, because I remember that when I saw it I had the distinct feeling that I was looking into the future. And Goggles is always fun.

Big thanks to Matt Douglas for helping us kick-off this series. More to come.

Share This

Posted by John Musser as BestPractices, CaseStudies at 12:09 AM | 3 Comments »

January 18th, 2007

Making Money From Mashups

A well attended Mashup Camp session hosted by Stephen O’Grady of Redmonk and StrikeIron’s Dave Nielsen lead to an active discussion on questions and issues around commercialization and business issues of APIs and mashups. Below are my rough notes from the session.

How are developer ecosystems best managed. Analogy made to old Microsoft Developer Network (MSDN) as a model of a classic, well-run developer program.
Concern from couple audience members about lack of responsiveness from API vendors. If I’m running a business, who do I talk to? Usually when they’re small the providers don’t respond to them. Sometimes developers have choices: easier to swap providers (ex one map provider to another), sometimes no alternatives.

Read the rest of “Making Money From Mashups” »

Share This

Posted by John Musser as BestPractices, Events, Issues, Law, Money, PopularAllTime at 12:05 AM | 11 Comments »

January 15th, 2007

Tell Yahoo What You Want

Over at the Yahoo! Developer Network blog, Jeremy Zawodny kicked-off the new year by asking developers What’s on your 2007 YDN Wish List? A good question that has drawn a healthy mix of responses.

New APIs: for media properties like Y!Movies, services like Yahoo! Calendar, custom search, and address book
More language-specific centers and tools (Yahoo! already has many): Flex2, ColdFusion, Java
Paid APIs for pay-as-you-go usage without limits
Greater API consistency (some of the issue is legacy from acquisitions)
Tools for developing “on Yahoo!” like Google’s GData APIs, aka the “Yahoo Operating System”
How-to screencasts
And lots of requests for free t-shirts

Later Yahoo!’s Kent Brewster announced they’d opened The Suggestion Box and cross-posted some of these over there.

Great to see an API provider inviting this level of open dialog and feedback.

Share This

Posted by John Musser as BestPractices, Issues, Yahoo at 12:02 AM | 4 Comments »

January 4th, 2007

How eBay Scales Their DevNet

Last month CIO Insight magazine published a piece by Edward Cone “Inside eBay’s Innovation Machine”, an interesting report on the importance of APIs and developer network to eBay’s overall strategy. It’s a worthwhile read, especially in terms of the scope of their program, how it’s run, and where the money is. Some highlights below:

40,000 independent developers from 100 countries in their network and it doubled in size between mid-2005 and mid-2006. During that period sellers using third party tools like Infopia increased by 50%. (Note that during that period eBay dropped API access fees see our coverage here). The story notes that 25% of eBay listings are created by third party tools using their API. And some misc eBay stats: nearly $50 billion worth of goods sold last year and 1.3 million people make their living on eBay.
Their developer community includes venture-funded companies like Terapeak (and Seattle’s Mpire, listed here but not part of report).
The success factors for a developer network including forums, tools, documentation, support, a sandbox test environment, knowledge base, certification program, developer’s conference, published product roadmap, and multi-language samples and SDK tools. (See also notes from Amazon’s Jeff Barr on their devnet.)
Developers have helped eBay reach new platforms like mobile, television and interactive voice.
Sometimes eBay-developer relationship is “complicated”. This can happen when strategic conflicts occur such as when eBay launched their own tool to compete with Terapeak. Terapeak’s marketing director Dave Frey notes that “eBay is a supplier, a marketing channel and a competitor.”
eBay has acquired developers, as they when they bought CARad, a specialized app for automotive listings. Note that Salesforce.com also has acquired developers using their platform.
From an infrastructure perspective they scale horizontally with the motto “If you can’t split it, you can’t scale it” (split-to-scale). A new version of their site is pushed every two weeks. For more on eBay’s infrastructure, this eWeek story notes they now run on 15,000 servers, mostly Sun and IBM.

Profiting their own open platform is certainly a big change from 1999 when eBay took outside developers to court.

You can see our eBay API and mashup listings here.

Share This

Posted by John Musser as BestPractices, Money at 1:23 AM | 2 Comments »

November 2nd, 2006

Follow Political Money via This API

Just in time for next week’s mid-term US elections, just listed here is this API from The Institute on Money in State Politics. And in this case, it’s the domain name that’s more telling: followthemoney.org. It’s quite an impressive store of data on the who, where, when and how much of campaign contributors across the US. From their site:

Money in state politics plays a pivotal role in shaping public policy in individual states and across the nation. The nonpartisan Institute on Money in State Politics tracks contributions in all 50 states and makes this data easily searchable online…The Institute collects campaign-finance data for state-level candidates, party committees and ballot-measure committees in all 50 states. Each two-year election cycle, data-acquisition specialists compile more than 90,000 disclosure reports from more than 16,000 candidates in the states and process more than 3.2 million records of contribution information.

There are about 30 API methods and are grouped by function: states, candidates, party_pacs, ballot_measures, and contributors. For code samples, use their interactive API tester and code generator.

They even offer a handy Widget Builder so you can place a widget on your site that displays live data about your (least) favorite candidate or PAC (political action committee). You’ll need to sign-up for an API key in order to use this, but it is a fairly painless process. Below is a screenshot of an example widget, in this case the Economic Sector Breakdown for Arnold Schwarzenegger in California for 2003.

For an earlier good mashup on visualizing where political money comes from, see Following Political Dollars.

On a similar vein, here are 15 mashups tagged ‘politics’ and 11 mashups tagged ‘advocacy’.

Share This

Posted by John Musser as APIs, BestPractices, Gov, News, PopularAllTime at 12:05 AM | 5 Comments »

September 4th, 2006

Adding An API to Your Web Service

Ryan Campbell over at Particletree wrote this nice introduction on How to Add an API to your Web Service. Good for beginning without too many assumptions about what you do or don’t know about things like REST or SOAP. He outlines many of the decisions you’ll have to make including data format support and error handling. See also some of the links in his Required Reading section for more.

Share This

Posted by John Musser as APIs, BestPractices, HowTo at 1:07 PM | 2 Comments »

August 23rd, 2006

Tips for Providing a Web API

Alex Bosworth over at Source Labs (and creator of the great open source resource SWiK) writes consistently good posts and Monday’s was no exception: How to Provide a Web API. In it he addresses the question of “What are a few simple rules for providing a web API?” with these five points:

Keep it clean and simple
Stick to standards
Make it about data
Keep it working
Design for updates

I completely agree with that list and might also add: a) provide examples, and b) document and support it. Neither of these need to be super extensive/expensive, just enough to get things kick-started (docs/examples) and help support the developer community as it grows.

This reminds me of Nat Torkington’s excellent post awhile back on How To Roll Out An Open API. He makes a good case that providers should: Make signup simple, offer toolkits for the languages that Internet developers use, and think laterally about business models. Recommended reading.

Share This