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

Stopping Web Services

Yahoo Photos is going away and Jeremy wonders what they should do about the API.

Reading about the pending closure of the Yahoo! Photos and Yahoo! Auctions (in US, at least) services leads to an interesting question for those of us in the business of providing free APIs to our services.

What’s the right way to decommission a Web Service API?

Clearly we ought to strive to shut things down in such a way that breaks people’s code the least (code that we’ve never seen and can’t influence).

There’s some good suggestions and thoughts in the comments.

This is right up the alley of Versioning Web Services in which I pondered the problems of improving an API while not breaking existing clients.

I’m looking for thoughts on how to version a web services API or really any software that’s delivered as a service. How do you prevent changes from having adverse effects while at the same time providing improvements. Is different API versions at different URLs really best or only way to go?

That post garnered some great comments as well.

This isn’t a new problem—at some point all software has to deal with how to end the support cycle for particular versions. However, with web services the problem is complicated because clients are fixed to the upgrade cycle of the server.

For a data structure or service delivered over the public web to a disparate set of clients, this isn’t possible. I cannot time the upgrade of the server to coincide with an upgrade of the client. In many cases, I don’t even know who the client is. I certainly don’t control them. And even if I knew them all, synchronizing an upgrade would require that I coordinate the upgrade schedules of multiple clients, maintained by multiple people, with varying degrees of interest and need.

Recently Written

Your OKR Cascade is Breaking Your Strategy
Aug 1: Most companies cascade OKRs down their org chart thinking it creates alignment. Instead, it fragments strategy and marginalizes supporting teams. Here's what works better than the waterfall approach.
Your Prioritization Problem Is a Strategy Problem
Jul 23: Most teams struggle with prioritization because they're trying to optimize for everything at once. The real problem isn't having too many options—it's not having a clear strategy to choose between them. Without strategy, every decision feels equally important. With strategy, most decisions become obvious.
Behind schedule
Jul 21: Your team is 6 weeks late and still missing features. The solution isn't working harder—it's accepting that your deadlines were fake all along. Ship what you have. Cut ruthlessly. Stop letting "one more day" turn into one more month.
VC’s Future Lies In Building Winners
Jun 21: AI and megafunds are about to kill the traditional venture model, forcing smaller VCs to stop hunting for hidden gems and start rolling up their sleeves to fix broken companies instead.
Should individual people have OKRs?
May 14: A good OKR describes and measures an outcome, but it can be challenging to create an outcome-focused OKR for an individual.
10 OKR traps and how to avoid them
May 8: I’ve helped lots of teams implement OKRs or fix a broken OKR process. Here are the 10 most common problems I see, and what to do instead.
AI is Smart, But Wisdom Requires Judgement
May 3: AI can process data at lightning speed, but wisdom comes from human judgment—picking the best imperfect option when facts alone don’t point the way.
Decoding Product Leadership Titles
Mar 18: Not all product leadership titles mean what they sound like. ‘Head of Product’ can mean anything from a senior PM to a true VP. Here’s how to tell the difference.

Older...

What I'm Reading