Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deactivating an API, one step at a time

apichangelog.substack.com

Post reply on HN
Print view View original

41–50 of 60 posts

Re: Deactivating an API, one step at a time

#41

Post by robogration »

I think one thing the author did not mention is telemetry. It is very dangerous to deactivate the service when there are still incoming traffic. Normally people only deactivate the service when there is absolutely zero incoming requests in an extended period of time.

Using old API as proxy as new API has its merit in that the callers needs to do little to pick up the logic change. However, often the old API are badly designed. Now you basically have two sets of APIs to maintain. When business requests come in, you might need to enhance the old API and the new API to support it. Of course, one could push the callers to switch to new API, but in a large organization, this often involves a lot of politics.

The difficulty of migrating/deactivating an API also depends on the implementation. If the API is a C++ library, it can be hard to tell how often the API gets called as you cannot tell whether the code path that contains your API is executed or not. For a HTTP or RPC service, at least you could put in some logs/metrics to check who is actually sending requests.

Re: Deactivating an API, one step at a time

#42

Post by michaelt »

tuyguntn wrote: post #27
michaelt wrote: post #3

> It might be that you want to replace it with a new, more capable version If you're truly replacing your API with a new, more capable version there's a much better option, in my experience. Roll out your new API, and replace your old API's implementation with a proxy that calls through to the new API. The proxy will need very little maintenance, as all it's doing is connecting one fixed, stable API (your old one) to…

This sounds a good idea in theory, but not sure about in real world. Consider having 4 versions of API, will you create 3 levels of proxies or each time re-write your old proxy? Sometimes, more capable mean additional side effects not existing in old contract (e.g. send an email about order), in that case your new API should be flexible to accommodate configuration of side effects, adding more maintenance cost to you…

> This sounds a good idea in theory, but not sure about in real world.

> Consider having 4 versions of API, will you create 3 levels of proxies or each time re-write your old proxy?

In the real world if you insist on breaking your paying customers' processes and products over and over again, pretty soon you won't have any paying customers any more, and you'll be free to make incompatible changes as often as you want.

Re: Deactivating an API, one step at a time

#43

Post by [deleted] »

michaelt wrote: post #3

> It might be that you want to replace it with a new, more capable version If you're truly replacing your API with a new, more capable version there's a much better option, in my experience. Roll out your new API, and replace your old API's implementation with a proxy that calls through to the new API. The proxy will need very little maintenance, as all it's doing is connecting one fixed, stable API (your old one) to…

[deleted]

Re: Deactivating an API, one step at a time

#44

Post by devin »

michaelt wrote: post #40
chipdart wrote: post #31

Earlier quoted context omitted.

> Roll out your new API, and replace your old API's implementation with a proxy that calls through to the new API. I don't think you understood the problem you're commenting on. The problem is not that you have a new fancy API version you expect users to consume. The problem is that you need to shut down the old API without causing customer or business impact. It makes little to no sense to pile up technical debt and…

> Your vague observation of how much work a API Gateway config takes is meaningless because you have no idea the impact of any change to the API will have on the older version fed through adapters. I don't think you've understood what I'm proposing here. When I release the V2 public API and invite my customers to code against it, they're going to start calling the methods I offer and expecting the response fields I p…

An assumption you're making here that you can even write an adapter layer for the V2 API. There may be things you wish to _remove_ in the V2 API. V2 does not always mean "add more stuff", it can often mean rethinking "what stuff" is provided.

Re: Deactivating an API, one step at a time

#45

Post by gofreddygo »

michaelt wrote: post #3

> It might be that you want to replace it with a new, more capable version If you're truly replacing your API with a new, more capable version there's a much better option, in my experience. Roll out your new API, and replace your old API's implementation with a proxy that calls through to the new API. The proxy will need very little maintenance, as all it's doing is connecting one fixed, stable API (your old one) to…

And voila! Just like that, you now have 2 systems to maintain, support and debug.

Do we redirect server side, use 302 or use JS to redirect ?

docs and api dont match, users don't RTFM, but lament that the engineering quality is low.

Support now needs to know which api endpoint the user with problems is hitting and why they cant repro when hitting the new endpoint.

Auth will be fun too, is it a domain redirect? subdomain? Cert rotations anyone ?

Re: Deactivating an API, one step at a time

#46

Post by beefnugs »

This kind of thing is important to consider, and could really change the world for the better in terms of more reliable world... Should we consider adding "user suggestion" as a feature to all APIs whenever possible? Clients could support by showing arbitrary messages to users, servers could say "this api will deprecate on 2024-07-10"

But capitalism crushes this to hell, imagine all the extra work to anticipate future problems, when "good enough, barely works" triggers immediate SHIP IT BOYS, then most engineers will just choose "someday shit stops working, oh well its not like this will be deployed in a nuclear reactor we hope they read the eula about that not being allowed"

Re: Deactivating an API, one step at a time

#47

Post by michaelt »

devin wrote: post #44
michaelt wrote: post #40

Earlier quoted context omitted.

> Your vague observation of how much work a API Gateway config takes is meaningless because you have no idea the impact of any change to the API will have on the older version fed through adapters. I don't think you've understood what I'm proposing here. When I release the V2 public API and invite my customers to code against it, they're going to start calling the methods I offer and expecting the response fields I p…

An assumption you're making here that you can even write an adapter layer for the V2 API. There may be things you wish to _remove_ in the V2 API. V2 does not always mean "add more stuff", it can often mean rethinking "what stuff" is provided.

Yes - that's why I included the proviso "if you're truly replacing your API with a new, more capable version"

If your intention is to remove features and fire the customers who are relying on them, that's a different matter.

Re: Deactivating an API, one step at a time

#48

Post by chipdart »

oasisbob wrote: post #34
chipdart wrote: post #31

Earlier quoted context omitted.

> Roll out your new API, and replace your old API's implementation with a proxy that calls through to the new API. I don't think you understood the problem you're commenting on. The problem is not that you have a new fancy API version you expect users to consume. The problem is that you need to shut down the old API without causing customer or business impact. It makes little to no sense to pile up technical debt and…

The post you're replying to is describing a straightforward implementation of the strangler pattern. It's a valid and useful technique. Even if you disfavor it, I don't see why you feel the need to judge the comprehension skills of the commenter. https://www.redhat.com/architect/pros-and-cons-strangler-arc...

> The post you're replying to is describing a straightforward implementation of the strangler pattern.

I'm not sure you are aware the strangler pattern is completely irrelevant to the problem of shutting down old versions of APIs still in use, specially when the goal is to shed maintenance needs.

Just because you are confident you can serve the same requests through an adapter, that does not mean you have less code to maintain and less work to do. Quite the opposite. And now your services also have to deal with more constraints as you're now bounded to comply with far more scenarios, some conflicting, from the same code base.

Talking about strangler fig patterns makes as much sense as blabbering about interfaces and dependency injection when talking about deleting old code. Irrelevant.

Re: Deactivating an API, one step at a time

#49

Post by chipdart »

gofreddygo wrote: post #45
michaelt wrote: post #3

> It might be that you want to replace it with a new, more capable version If you're truly replacing your API with a new, more capable version there's a much better option, in my experience. Roll out your new API, and replace your old API's implementation with a proxy that calls through to the new API. The proxy will need very little maintenance, as all it's doing is connecting one fixed, stable API (your old one) to…

And voila! Just like that, you now have 2 systems to maintain, support and debug. Do we redirect server side, use 302 or use JS to redirect ? docs and api dont match, users don't RTFM, but lament that the engineering quality is low. Support now needs to know which api endpoint the user with problems is hitting and why they cant repro when hitting the new endpoint. Auth will be fun too, is it a domain redirect? subdom…

> And voila! Just like that, you now have 2 systems to maintain, support and debug.

It's even worse, the "new" system is a layered mess where logic is spread across multiple systems and services, and is bound to accommodate all the original scenarios and ensure new changes remain compatible across multiple versions.

It's a far worse situation than keeping the old APIs in. It's a proposed solution from someone who clearly did not even read the problem statement.

Re: Deactivating an API, one step at a time

#50

Post by chipdart »

taeric wrote: post #24
n4r9 wrote: post #18

Earlier quoted context omitted.

What if the new API is more capable precisely because the parameters have been completely redesigned?

The presumption would be that there is a mapping from the old parameters to the new? Not necessarily a simple shift/rename, but you aren't doing your users any favors if they have to speak an incompatible vocabulary to make use of the new system.

> The presumption would be that there is a mapping from the old parameters to the new?

"Presumption" is a funny word when used to say you didn't considered the part which happens to be the cornerstone of the whole proposal.

You can't just hand wave over the core part of the whole proposal, and just say "well I expect it to somehow already be working and serving it's purpose", specially when the question is on what happens when this mapping is either practically or theoretically impossible.

Just think through the problem and consider small mundane details such as the fact that the decision to create a new API version is never taken lightly, and different API versions are created to accommodate breaking changes. Think about problems such as: what if resource IDs are incompatible and entirely different? On top of that, what if the old API returns references to different resources than the new API? How do you solve that with "mapping"? Are you suggesting we roll out a mapping service?

Post reply on HN