Need someone to lead product management at your software company? I create software for people that create software and I'm looking for my next opportunity. Check out my resume and get in touch.

This is the blog of Adam Kalsey. Unusual depth and complexity. Rich, full body with a hint of nutty earthiness.

Product Management

Is an API really needed?

Freshness Warning
This blog post is over 17 years old. It's possible that the information you read below isn't current and the links no longer work.

Drew McClellan suggests that perhaps your website could be your API, using microformats, semantic HTML, and a little screen scraping.

Almost three years ago, John Udell suggested something similar and I wrote a rebuttal. Much of it applies to McClellan’s suggestions, too. Here’s a reposting of my original piece.

Jon Udell waxes nostalgic about the good old days of screen scraping HTML in order to build the first generation of Web services. That’s great and I’ve built my share of screen scraping applications as well. But then Udell goes on to propose that companies should abandon modern Web services technologies in favor of screen scrapes helped along by well-formed XHTML.

Udell’s reasoning is that Web services through SOAP is too complicated. "But if I’d had to register for an API key and locate WSDL documentation for each of the three services whose results I compared, I probably wouldn’t have bothered," he says. His entire argument is based on his experiences with the Google API and their specific SOAP implementation.

Google requires that anyone using their API register for and use an API key—an identifying token that lets Google track the usage of their API down to a specific user or application. Google requires it, but the SOAP protocol does not. Most SOAP services don’t have any sort of key and if you were building a tool for an intranet, you probably wouldn’t need or want such a scheme. Not only does Udell miss that point, but he also forgets that SOAP isn’t the only Web services technology.

Udell says that a primary threat to your intranet is disuse. If people find it too difficult to create and use information on the intranet, they won’t bother. That’s true; if you create onerous processes that content creators must follow, they’ll find ways around them, publishing their information in ways that you don’t expect. But Udell’s assertion that building data access through Web services will make it too difficult for people to use your data is preposterous. Screen scraping is more difficult and more apt to fail than using stable, published APIs. And with REST, the APIs are just as easy to access as any other Web document.

As an example, let’s use product data for my new camera. What’s easier—scraping $1 or getting it in XML format from their REST interface? For each method I have a unique URL that I request to get the data. There aren’t any complicated steps to follow for either system. But the HTML version, even if it were well-formed XHTML, would be significantly harder to retrieve meaningful data from. And changes to the display of the information would often mean changes to the structure of the HTML, necessitating further changes to my screen scraping application. Amazon does require a developer’s token (an API key, essentially), but again, that’s only so they can control usage. There’s no reason at at all that a REST system like this couldn’t be built without it.

But doesn’t creating a REST interface mean more work for the content producers? Probably not. Presumably your corporate intranet is using some sort of content management system. Otherwise there’d be no way to enforce this XHTML-only rule. Furthermore, that content management system probably stores the content in a database somewhere separate from the presentation of said content. All you need to do is build one REST interface that retrieves the required content from that database and presents it as a pre-determined XML document instead of an HTML document. The content producers could go along creating content as they always have, blissfully unaware that they are also populating a Web service.

Udell’s XHTML scraping suggestion has significant risks as well. Remember that making the process of content creation difficult will ensure that people find other ways to create content—ways that you don’t control. But in advocating screen scraping, Udell says, "it’s true that creating XHTML pages requires more discipline than hacking out HTML, and it may incur some retraining costs." Not only are you going to make it difficult for people to build systems that automatically consume information, but you also propose making it more difficult to create it?

People will flock to things that are easy. RSS took off because it was easy to create and easy to consume. Sure, it would be possible to create screen scraping applications that would take any well-formed XHTML content source and pull that content into a newsreader. But it’s much easier for everyone concerned to create a simple, easy-to-understand format that contains all of the information in logical chunks and just run with it.


Drew McLellan
October 23, 2006 1:26 PM

Hi Adam. My presentation wasn't about screen scraping at all - I didn't even mention it. Not sure how you got that impression, but a podcast is available, so do take a listen if you get the chance. (btw, it's McLellan with one C, but no sweat).

This discussion has been closed.

Recently Written

Micromanaging and competence (Jul 2)
Providing feedback or instruction can be seen as micromanagement unless you provide context.
My productivity operating system (Jun 24)
A framework for super-charging productivity on the things that matter.
Great product managers own the outcomes (May 14)
Being a product manager means never having to say, "that's not my job."
Too Big To Fail (Apr 9)
When a company piles resources on a new product idea, it doesn't have room to fail. That keeps it from succeeding.
Go small (Apr 4)
The strengths of a large organization are the opposite of what makes innovation work. Starting something new requires that you start with a small team.
Start with a Belief (Apr 1)
You can't use data to build products unless you start with a hypothesis.
Mastery doesn’t come from perfect planning (Dec 21)
In a ceramics class, one group focused on a single perfect dish, while another made many with no quality focus. The result? A lesson in the value of practice over perfection.
The Dark Side of Input Metrics (Nov 27)
Using input metrics in the wrong way can cause unexpected behaviors, stifled creativity, and micromanagement.


What I'm Reading