A project I’m working on currently depends on several SDKs and APIs that perform identical tasks, but for different external products. For example, in an Internet of Things world we have a common interface of TurnOn, TurnOff, GetStatus, etc. Having all of these dependencies in the meat and potatoes of my project is getting messy, and I want to pull it out into a separate web service that exposes these common functions over a REST API.
My question is this: What is the recommended architecture for having a web service expose a REST API that, when called, resolves the requested IP to the correct SDK and goes through the standard request/response cycle? Especially in a way that scales and handles SDKs that expose methods in different programming languages.
For context, here is an example request that the API might expose… /things/{ip address}/turn_on, which would then resolve that the IP address belongs to a Hoover vacuum and make a call to the Hoover vacuum SDK, which might expose methods written in C#. Alternatively, it might resolve that the IP Address belongs to a different brand of vacuum which exposes its methods in C++.
Design and build a REST API first. Be careful — it really isn’t as easy as it looks. Stateless, cacheable, resource identifiers not addresses. Not that easy.
Then simply implement by abstracting over the concrete implementations you’ve already done. You will have to make tech choices, but you haven’t told us anything about your contraints. For example, what kind of server would you choose?
As to your example, it has problems.
- The REST endpoint should probably be /things/vacuum/{id}
- you would need to send it a POST request (GET cannot change state)
- POST data would probably contain the field “power=on”.
1