Mashups, Web Data, and APIs


Frank mantek, Jeff Barr, Dan Theurer, and Kevin Lawver
Frank Mantek, Jeff Barr, Dan Theurer, and Kevin Lawver
(click to enlarge)

I decided to take in Rohit Khare's panel on Next Wave (Business) this morning. This was part of the developer track that has normally been Rohit was kind enough to invite me to the panel dinner last night. It was fun and I

Dan Theurer from Yahoo! was first up and used the theme "What Powers Web 2.0 Mashups?" Dan introduced the Yahoo! Developer Network. The first APIs that Yahoo! launched were the search APIs a little over a year ago. He showed a long list of APIs that Yahoo! has released since then. You can get to a lot of Yahoo! content at this point.

The Yahoo! APIs are RESTful. The standard format is hostname, service, version, and call. XML is the default response. JSON can be used to avoid XML parsing and the need for proxies.

Dan points out some mashups. The first he mentions is Rollyo for rolling your own search engine. You can create custom search domains using a simple user interface. He also mentioned an event browser which I couldn't get to come up. I don't know if it's protected or just the network here at the conference.

The second panelist was Kevin Lawver from AOL. He talked about a microformat for widgets. Yahoo, Google, AOL, and other's all have widgets, but they don't talk to each other. Kevin sees microformats as an answer to that. He came up with a microformat called MicroT. This works in Aim Pages. He was also able to make it work in Dashboard. He demoed this using a widget he wrote for AimFight. Using a microformat for this allows a single, human readable format that can easily machine translated into other formats.

Frank Mantek from Google spoke about the Google Data API. Google, has lots of APIs available all kinds of things. Google Data API is a single API for querying and updating data across multiple applications. For example, here's the data API for Google Calendar. The API supports Atom and RSS. Updates are based on Atom.

There are a number of common elements (kinds) and some that are application specific. Google Calendar defines three kinds of data: events, contacts, and messages. Right now there are Java and C# libraries. A PHP library is in the works.

To make this really useful, you have to have 3rd party authentication so that other Web sites can authenticate Google users for purposes of getting Google data for that user. I wrote about this earlier, before it was fully baked. Sophisticated mashups are going to require authentication to sites that own data.

The forth speaker was Jeff Barr, Amazon's Web services evangelist. Jeff introduced the various APIs that Amazon supports. Jeff lists some best practices:

  • First, have a program
  • Get the business model right
  • Get the technology side right
  • Support developers
  • Create community

The business model comes down to two choices: services enhance your business (the Doc Searls "because" business model) or services are your business. You need a good pricing strategy and a good license. You have to strike a balance between protecting your assets while also being permissive so that you allow the unexpected. Make it easy to get started.

On the technology side, start simple and support multiple protocols (SOAP, REST, JSON). Be a platform, meaning have a version strategy and strive for backwards compatibility. Ensure you're scaled for growth so that you don't have a "success disaster."

To have a developer program, you need more than just APIs. You also need extensive documentation, sample code, and technical support. Developers will count on you for their success, so they need support.

Building a community means forums, outreach, evangelism, blogging, and lots of random interaction. You have to get out and talk to people. Work hard to get into situations where interactions can happen.

Rohit brings up the Web 2.0 phenomenon of looking at the intersection of services and once you find an empty spot, you've got a start-up.

I asked about the multiple authentication problem. Google's authentication system works similar to OpenID in that it allows you to get a key which than can be later repudiated by the owner to deny that service access. Getting multiple services from different vendors in a single application would require storing multiple keys. In many cases, this would require users trusting 3rd parties with their login information. Jeff mentioned that there are already 3rd party sites that ask users for their Amazon user ID so that they can create an S3 account for them. Scary...

There was considerable discussion of security concerns on mash-ups. This hasn't been a big topic yet, but will be. All of the panelists said their company does things to prevent cross-site scripting, cookie stealing, and so on in their services. Rohit mentioned that in a simple service they built at CommerceNet the sanitization code was have the application.