I mean, for every JS front end, I make an API backend. So every website I make is an external API. And then those API backends also call data APIs, some of which are my responsibility, and are used by other internal teams (same effect as an external user).
For web backends, I have the JS client call an endpoint that returns a version, and then at a set interval, checks to see that the version hasn't changed. When a new version of the application (front end and back end) is deployed, the user gets a notification that the application has been updated, and they need to refresh the page. Each JS/CSS file bundle is versioned and placed in the cache when deployed, and the initial page load includes a manifest, and script loaders reference the manifest rather than the source filepaths.
Data API references tend to break clients when changed. So in that case, each version gets it's own application folder (I host on IIS), with the application folder specified in custom TFS build arguments - source is branched appropriately. Those get deployed, and then clients can start consuming the new version. When the old versions no longer get any traffic, change management occurs to decommission them. If we had external customers using the APIs, we would send out a communication rather than using change management.
None of the APIs I maintain have a daily call limit or are terribly complex. There's a variety of different technologies (SOAP/XML, JSON, OData v3-v4) and different firewalls and auth protocols. I couldn't tell you anything about hosting a complex one like Google's Analytics API (although I've consumed it, and bravo to them for making it at all usable).
I'm not a fan of BizTalk (lack of innovation), haven't used MuleSoft - tried AppFabric but it didn't go so well. Once .net core gets more established, I'd like to rewrite them all and host them on a docker swarm with windows server nano images.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
More details would help. What kind of APIs?
I mean, for every JS front end, I make an API backend. So every website I make is an external API. And then those API backends also call data APIs, some of which are my responsibility, and are used by other internal teams (same effect as an external user).
For web backends, I have the JS client call an endpoint that returns a version, and then at a set interval, checks to see that the version hasn't changed. When a new version of the application (front end and back end) is deployed, the user gets a notification that the application has been updated, and they need to refresh the page. Each JS/CSS file bundle is versioned and placed in the cache when deployed, and the initial page load includes a manifest, and script loaders reference the manifest rather than the source filepaths.
Data API references tend to break clients when changed. So in that case, each version gets it's own application folder (I host on IIS), with the application folder specified in custom TFS build arguments - source is branched appropriately. Those get deployed, and then clients can start consuming the new version. When the old versions no longer get any traffic, change management occurs to decommission them. If we had external customers using the APIs, we would send out a communication rather than using change management.
None of the APIs I maintain have a daily call limit or are terribly complex. There's a variety of different technologies (SOAP/XML, JSON, OData v3-v4) and different firewalls and auth protocols. I couldn't tell you anything about hosting a complex one like Google's Analytics API (although I've consumed it, and bravo to them for making it at all usable).
I'm not a fan of BizTalk (lack of innovation), haven't used MuleSoft - tried AppFabric but it didn't go so well. Once .net core gets more established, I'd like to rewrite them all and host them on a docker swarm with windows server nano images.