shaneqld
commented
3 years ago I think your question might be too abstract to wrap my head around. (Sorry)
Without more specifics, my only advice is that you should include the information in your API that your client will need, and that the implementation of your service is responsible for sticking to the interface that you've designed.
Occasionally abstractions are more or less complete, and the user of the new API can forget that the previous versions or data structures existed. However in many cases it becomes necessary on rare occasions to determine some details of the underlying implementation to account for bugs or differences in algorithm.
Sounds like something that should be happening server-side that should be transparent to the client.
It might be worth posting your design problem to Stackoverflow to get more specific assistance.
In some cases an API is an abstraction layer that "wraps" multiple APIs, to provide a uniform interface or simply to create a more modern/idiomatic interface. Occasionally abstractions are more or less complete, and the user of the new API can forget that the previous versions or data structures existed. However in many cases it becomes necessary on rare occasions to determine some details of the underlying implementation to account for bugs or differences in algorithm.
For example, an SDK might provide an abstraction layer over different models of temperature sensor. If one of these sensors is defective, the client might want to disregard data from these sensors, or apply a corrective offset, etc.
Another example is the APIs provided by web browsers: client code not only needs to determine what capabilities are supported, but also in some cases needs to avoid bugs in implementations. A variety of techniques are used to accomplish this (some more satisfying than others).
Do you have any guidance for thinking through the different techniques that can be used to break the abstraction when necessary (versioning? labelling the source data?) and their tradeoffs?