Hacker News Reader

Comment by pbreit | Hacker News Reader

I've always thought APIs should try to avoid versioning. It's usually pretty easy to enhance APIs in a backwards-compatible manner. It also forces smarter design and restraint. Existing users rarely update integrations until they are forced and then it is a major pain just to stay in place.

View on HN

If you don't version, you can only add to an API. You cannot change anything meaningful (or as simple as renaming a field). You wind up with APIs with multiple ways of getting the same or similar data in order to avoid breaking backwards compatibility, which leads to bloated, confusing APIs.

> You cannot change anything meaningful Sure you can. I think it's great that a lack of versioning discourages things like renaming a field. It's with versioning where you wind up with...multiple versions.

The problem with this is when you do something stupid. Let's say your GetFrobz interface is missing something, or requires a parameter it doesn't really need, or just stupidly keeps state around to provide a feature that's not important. If you don't have versioning, but want to replace this, you have to call it something different.

So now you have GetFrobz and FetchFrobz and you need to tell everyone to not use GetFrobz in new applications.

This really does happen. The first example that comes to mind: is POSIX random numbers (rand,random,drand48), but there are loads of others anywhere that backwards compatibility is deemed important.

Reply on news.ycombinator.com