RSS MAD

Daniel Steinberg posts comments from a talk Adam Bosworth [from Google] gave at a recent MySQL users conference regaring web services and taking the simple approach instead of the complex approach. With programming [i.e. the web] simple is always the preferred route to take if at all possible, and it usually is. But we all know that's easier said than done, especially when we're dealing with complicated data. Web services standards, usually via xml, are meant to make our lives easier but in actuality they complicate things and add a lot of unnecessary overhead to data that can usually be returned in a simple csv file.

In his Thursday morning keynote at the MySQL Users Conference 2005, Google's Adam Bosworth suggested that we "do for information what HTTP did for user interface." Ten years ago, when he first started paying attention to the web, he was interested in the idea that he could zero install applications and that they could be accessed from anywhere at any time. He said that a personal computer to him is like a phone: it is a useful access point but it is not where he stores stuff.

He went on to say...

Bosworth advocated an open model for data. Although he was not referring to open source, he expanded upon the example by explaining that customers like open source software because of the transparency. For many, they know what they are getting because they can read the source. For the most part, they do not actually read the source, but it is comforting to know that if the software doesn't work, you or someone else can fix the code if that is required.

Imagine if you can query any data that is available anywhere in the world. Bosworth said that what this requires is a single, simple, open wire format for items. The format needs to be simple for any P programmer to deliver and any JavaScript programmer to consume. He also pointed out that "complex things tend to break and simple things tend to work." Google has the simplest query language in the world. There is no structure and no syntax.

Bosworth predicts that RSS 2.0 and Atom will be the lingua franca that will be used to consume all data from everywhere. These are simple formats that are sloppily extensible. Anyone who wants to can use these formats to consume content or to author content. Contrast this with the Semantic Web, which requires that you get a large group of people to agree on the schema of everything.

The only question I have is why Google implemented such a complex web services platform. I mean you can access their api from every conceivable web service method except RSS and Atom... hmmm. Now the blogger boys are using Atom and have been big proponents of it but I wish that would catch on over on the Google side of the cafeteria.

Textamerica has launched their developer api, along with a contest:

To help launch our new Developer Program we will pay $500 for each of the first 20 applications (with source code) based on this API which are developed by you, and which we deem to be the most useful to the Textamerica Community as a whole. This is not a contest but merely our way of showing our appreciation for what you do.

Amazon has made some minor updates to the Amazon ECS web services. Check out the Amazon Web Services Blog for the details.

43 Things has just released a fresh new REST web service for accessing their content. If your not familiar with 43 Things it is a social networking web site where people with common goals can site include to stop procrastinating, loose weight, take more pictures, and so on. Goals are tagged with keywords, and you can also see which goals are popular in a particular city.

With the 43 Things web service you can access goals (add, complete, list), people, teams, tags, and cities.

When using the Google Search API I noticed that google there is a discrepancy between a Google search on their web site, and a google search using their web api.

Google claims that:

With the Google Web APIs service, software developers can query more than 8 billion web pages directly from their own computer programs. The Google web search API uses the SOAP and WSDL standards.

If you do a Google search for the letter a, the most common letter in the English language from Google's web site you will get 8 billion results. Now if you try this search from the Google API you only get 5.2 billion results.

Note that I have filtering turned off on both the Google Web site, and in the Google API (with filtering turned on you get about 2.8 billion results).

So the question is, where are those other 3 billion results? Google claims that you can access all 8 billion pages in their index with the API, but my results show otherwise.

The folks at Blogger have updated their Atom API this week. The new updates allow for secure authentication over HTTPS (using HTTP Basic authentication), and i18n (internationalization) support, and other bug fixes.

You can find documentation here, and the BloggerDev mailing list here.

The Atom API is a REST style web service API, which means you simply use the HTTP protocol with GET, POST, PUT, and DELETE commands. For instance if you want blogger to return a list of blogs for an account go to https://www.blogger.com/atom and login with your username. The result of the GET command will be an XML representation of the blogs you author.

The Atom API allows you to:

• Get a list of a users blogs
• Get an atom feed of a blog
• Get an atom feed of a blog entry
• Create a new blog entry
• Edit a blog entry
• Delete a blog entry

Sometimes other folks can say it better than I can so I'll let Olivier tell you what's up with Google's new AdWords API and what it means.

"Some possibilities might include:

• Generating automatic keyword, ad text, URL, and custom reports


• Integrating AdWords data with databases, such as inventory systems


• Developing additional tools and applications to help you manage accounts"

Code samples are provided in Java, C#, XML, PHP and Perl, with more emphasis on the last one. There's a discussion group for developers and a blog, though they're obviously not very busy places yet. They use an interesting quota system to throttle API calls based on ad spending.