Service Agnostic API Wrapper Library Project Structuring
I've been developing a library for interacting with an API, and now that I've been developing it somewhat, I've realized that there's a few similar APIs that I'd like my library to interact with. One of these APIs has nearly identical endpoints, and for the identical endpoints, I was able to successfully deserialize the JSON using my existing JSONProperty annotations and Converters (although the responses are not fully 1:1).
I was just wondering, how should I restructure the project in a way that users can select the API they want to use? If I were to make an interface (and have the library consumers select the concrete implementation), some of the APIs have endpoints that others lack.
3 Replies
@viceroypumpkin | 🦋🎃 you might have an idea
Here's an example of two endpoints from different APIs which are quite similar but differ slightly in endpoint and responses:
https://opendata.adsb.fi/api/v2/lat/33.942/lon/-118.410/dist/50
https://api.airplanes.live/v2/point/33.942/-118.410/50
don't reuse models of one api for another one, at least if you are not certain they expose the same standard
if they are not the same model, then use different models. then if, or more realistically, when one changes, then it won't break the other. only time you should use the same model is if the openapi spec explicitly declares that they are using the same model
if you want to abstract a choice of which one to call, then normalize them to a common model after deserialization, not before.