21–30 of 60 posts
> In addition to offering human-understandable communication, I asked the API producer to add the Deprecation HTTP header field to all responses Cute, but, I question the value
As a consumer, you can set up an alert when any of your API requests has a deprecation or sunset HTTP header. You'd know immediately if any of the APIs you depend on is about to be deactivated.
It would be really cool to see a graph of the API usage over time with markers showing when each "stage" was occurring. I'm wondering if there were significant dips shortly after each stage, or if it was more of a gradual decline? It would also be interesting to know if the API was still being used up until the final stage? Were there any ramifications/ angry customers at the door after that?
I'll write about it the next time I'm in a similar situation.
> 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…
> 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…
What if the new API is more capable precisely because the parameters have been completely redesigned?
Earlier quoted context omitted.
Or instead of losing paying customers: 1. design API accounts to include a preferred server and default server (handy to explicitly load balance, or dynamically bounce users to specified servers.) 2. design clients to have a timed service lifecycle (expiry 2 weeks prior to cert expiry). Then enter a semi-dormant mode until valid signed updates succeed. 3. add a random timed daily update check, and begin reassigning t…
Yes, I completely agree. The story sounds like fairytale: migration was announced to happen in 3 months and in 4 months it was done by removing old API. Where are all those clients, who are happy with current API performance and do not want to spend their money on making API owners life better? What happened to them? Did the company just decide to let those clients go?
If they can't spare the engineering time in the next six months to carry out the upgrade (and you aren't 100% mission critical to their business) they're not going to do that no matter how much you bug them.
Depending on how old the integration is they may not even still employ the engineers who built the first version, which makes it even harder for them to roadmap the work.
Earlier quoted context omitted.
Yes, I completely agree. The story sounds like fairytale: migration was announced to happen in 3 months and in 4 months it was done by removing old API. Where are all those clients, who are happy with current API performance and do not want to spend their money on making API owners life better? What happened to them? Did the company just decide to let those clients go?
Yeah, one of the biggest problems with API deprecation is that you have zero control over the roadmap of your clients. If they can't spare the engineering time in the next six months to carry out the upgrade (and you aren't 100% mission critical to their business) they're not going to do that no matter how much you bug them. Depending on how old the integration is they may not even still employ the engineers who buil…
1. if it succeeds, the manager looks smart given your services are no longer relevant to their operations
2. if it fails, the manager looks smart as they are not responsible for the external firms business operations
It is a win-win situation for the client, but 100% bad for your business... =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…
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 your eng. org
> 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…
Earlier quoted context omitted.
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…
also, the assumption here is "more capable = same features + something new (no removals)", sometimes you have to delete some features as part of new API (e.g. stop creating audit log entry for an action).
> In addition to offering human-understandable communication, I asked the API producer to add the Deprecation HTTP header field to all responses Cute, but, I question the value
I came here just to say that. What an half-baked idea. It might be trivial to mindlessly bolt on response headers, but if the goal is that the mechanism needs to be impactful and have consequences then the response header is a big red herring as you're actually relying on clients to implement support for sunsetting the endpoints. If that's the case then you already have meaningful mechanisms, such as passing this sort of metadata in responses to requests for the root resource. This is something that pretty much any HATEOAS spec already supports.