Delicious

Delicious is where the whole thing started for me, and I don’t say that lightly. I remember the moment clearly: in 2004 I changed the URL for my Delicious social bookmarking account to make it return a list of my bookmarks as XML instead of HTML, and something clicked. It was a vision of the programmable web — where everything I explored on the internet wasn’t just consumable as a web page, but where right below the surface of any website or application there was also a machine-readable version, allowing me to build whatever I desired. That single act, swapping HTML for XML by changing a URL, is the origin of the worldview that became API Evangelist. I have spent the rest of my career chasing the feeling I had in that moment. Delicious didn’t just have an API — it was the API that taught me what APIs were for.

Delicious — originally stylized as del.icio.us, one of the great domain hacks of the era — was founded by Joshua Schachter in 2003, and it was a pioneer of social bookmarking. The idea was simple and, in retrospect, profound: instead of keeping your bookmarks locked in your browser, you stored them on the web, where you could access them from anywhere, share them, and — crucially — see what other people were bookmarking. It was one of the defining Web 2.0 applications, and it introduced a generation of users to ideas that are now everywhere but were genuinely new then. When I wrote the history of Delicious in 2013, the thing I kept coming back to was how much of what we now take for granted was either invented or popularized by this one small service.

Tagging and folksonomy were Delicious’s great conceptual contributions. Before Delicious, the dominant model for organizing information was the hierarchy — folders inside folders, categories defined from the top down. Delicious let users attach freeform tags to their bookmarks, and then aggregated those tags across all users into what came to be called a folksonomy: a classification system that emerged from the bottom up, from how actual people actually labeled things, rather than from how an authority decided things should be labeled. This was a radical idea about information architecture, and it spread everywhere — the tag is now a fundamental primitive of the web, and Delicious is a big part of why. The folksonomy was also, in a sense, an early lesson in the power of aggregated API-accessible data: the collective tagging behavior of the user base became a resource more valuable than any individual’s bookmarks.

The API itself was a model of the early RESTful approach, and it’s worth being precise about why it mattered technically. Delicious delivered its data over HTTP in a clean, simple, predictable way — you could get your bookmarks, your tags, your network, all through straightforward HTTP calls that returned structured data. This was during the period when the industry was still arguing about SOAP and the heavyweight WS-* stack, and Delicious was quietly demonstrating the alternative: just use the web the way it was designed, return data at URLs, keep it simple. When I reviewed the Delicious API in 2010 as part of my early building-blocks research, what struck me was how much it got right by keeping things minimal. It was an HTTP API that any developer could understand and start using in minutes, and that accessibility is exactly what made it a gateway drug for people like me who were discovering what the programmable web could be.

The personal thread matters here because Delicious is woven into my own origin story in a way few other platforms are. When I’ve written about what it was about web APIs that first captured my attention, Delicious is always at the center of it. It wasn’t an enterprise integration or a payment system or anything that smelled like business — it was a tool I used every day, made suddenly programmable, and that combination of personal utility and machine-readability is what hooked me. I still use API-driven bookmarking every day; my bookmarklet workflow for profiling and recording APIs descends directly from the Delicious habit. The 2024 bookmarklet I built to profile APIs is, in a real sense, the same impulse I had in 2004, just turned toward my own work. Delicious taught me that an API is most powerful when it sits underneath something a person already loves to use.

Then Yahoo happened, and Delicious became one of the canonical cautionary tales about what acquisition does to a beloved platform. Yahoo acquired Delicious in 2005, and over the following years the service withered under corporate ownership — neglected, nearly shut down, leaked internal slides in 2010 showing it was on a “sunset” list, eventually sold off and passed through a series of owners who never recaptured what it had been. For a lot of us who depended on Delicious, this was a formative experience in API impermanence. It’s part of why I’ve written so many times that APIs are not forever — that they can go away at any time, that developers who assume permanence are setting themselves up for pain, and that there are many ways in which APIs are taken away from the people who built on them. Delicious is exhibit A. A platform you love, with an API you’ve built your workflow around, can be acquired and slowly killed by a company that never understood why it mattered.

But the Delicious story has a redemptive second act, and it’s one of the most important case studies in the entire history of API copyright and reuse: Pinboard. When Delicious’s future looked grim, Maciej Ceglowski built Pinboard — a paid, deliberately minimal, anti-VC social bookmarking service — and crucially, Pinboard reimplemented the Delicious API. Because Pinboard spoke the same API as Delicious, all the tools, clients, and workflows that had been built for Delicious could work with Pinboard, and users could migrate their entire bookmarking life from a dying platform to a healthy one. This is the single best real-world example I have ever had for why API designs must not be copyrightable. When I signed onto the EFF briefs in the Oracle v. Google fight, and kept signing as it headed toward the Supreme Court, Pinboard reimplementing the Delicious API was the example I reached for again and again. If API interfaces could be copyrighted, Pinboard couldn’t have done what it did, and users would have been trapped on a sinking platform with no way to take their workflow with them. The freedom to reimplement an existing API is what made user data portability real in this case. The menu is not the restaurant — Pinboard could legally offer the same menu, and it saved a community.

Pinboard also became, for me, the model of how to run a sustainable API business, and I’ve held it up as an example repeatedly. Ceglowski built Pinboard without venture capital, charged users actual money, kept the operation deliberately small, and ran it profitably for years — eventually buying Delicious itself in 2017, closing the loop by acquiring the very service whose API it had reimplemented. I called Pinboard the number one API example you should be following, and I meant it: in an industry obsessed with growth, free tiers, and VC funding, Pinboard demonstrated that you could build a durable, honest, profitable API business by charging a fair price, treating users with respect, and not trying to be bigger than you needed to be. The 2016 episode where the IFTTT CEO had to publicly address Pinboard customers was a small drama about open-web values and platform respect, and Pinboard came out of it looking like the principled party because it had always been the principled party.

The throughline from Delicious to Pinboard contains most of what I believe about APIs. It starts with the revelation that the web could be programmable — that changing a URL to get XML instead of HTML opens up a world of possibility. It runs through the demonstration that simple, RESTful, HTTP-based APIs win over heavyweight alternatives because they’re accessible. It includes the hard lesson that platforms you love can be acquired and killed, that no API is permanent, and that depending on someone else’s API is always a risk. And it resolves in the proof that open, reimplementable API designs are what give users freedom — that because the Delicious API wasn’t locked up by copyright, a community could escape a dying platform and a sustainable business could rise to serve them. Delicious gave me the vision. Yahoo gave me the warning. Pinboard gave me the model. I’m not sure any single thread in the history of APIs has taught me more.

Guidance

API Learnings

APIs

API Governance

API Solutions

API Discovery

API Building Blocks

API Evangelist LLC

Delicious

References

Guidance Details

Explore more

Discover APIs