Need someone to lead product or development at your software company? I lead product and engineering teams and I'm looking for my next opportunity. Check out my resume and get in touch.

Stopping Web Services

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

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.

max
May 11, 2007 8:19 AM

Stopping has 2 p's.

Adam Kalsey
May 11, 2007 8:41 AM

And you don't use apostrophes when pluralizing a word. That would be "P"s unless you're telling me that something belongs to the P.

This discussion has been closed.

Recently Written

How to advance your Product Market Fit KPI (Oct 21)
Finding the gaps in your product that will unlock the next round of growth.
Developer Relations as Developer Success (Oct 19)
Outreach, marketing, and developer evangelism are a part of Developer Relations. But the companies that are most successful with developers spend most of their time on something else.
Developer Experience Principle 6: Easy to Maintain (Oct 17)
Keeping your product Easy to Maintain will improve the lives of your team and your customers. It will help keep your docs up to date. Your SDKs and APIs will be released in sync. Your tooling and overall experience will shine.
Developer Experience Principle 5: Easy to Trust (Oct 9)
A developer building part of their business on your product needs to believe that you're going to do the right thing for them and their customers.
Developer Experience Principle 4: Easy to Get Help (Oct 8)
The faster you can unblock a stuck developer, the better their experience will be.
Developer Experience Principle 3: Easy to Build (Oct 5)
A product makes it Easy to Build by focusing on productivity for developers building real-world applications.
How to understand your product and your market (Sep 30)
A customer development question you can ask to find out who your product is best for and why they'll love it.
Developer Experience Principle 2: Easy to Use (Sep 28)
Making it Easy to Use means letting the developer do everything without involving you.

Older...

What I'm Reading

Contact

Adam Kalsey

+1 916 600 2497

Resume

Public Key

© 1999-2020 Adam Kalsey.