I'm asking this question coming from a background of no experience in web development, so please be patient as I attempt to explain what I'm doing (if I use the wrong terminologies or if this has already been asked. Tried searching, but I don't exactly know how to concisely ask this question).
I have a server I've developed that handles requests from some embedded devices that my company builds. Currently, this server just acts as a file server, but it'll be a lot more in the future. Let's say for sake of example here that I want to build a webpage that gets the available files accessible to these devices, and displays them to the page.
I figure this is a job for a REST API, but I'm a bit confused over implementation details here. I see things as being as so: [devices] --> server <-- REST API <-- Webpage (arrows indicate which way requests flow).
So, here is where I get confused. Should I leave my server as it is, and build a connector class for the REST API, or is there a way to integrate a REST API into my existing project (or vice versa, implement the server into the REST API project). The way I've seen REST's built in all the tutorials I've followed they typically connect to a database with their model classes, from the controllers. I don't know how this plays out when the model isn't coming from a database (and as a result, no Entity Framework). I just figured I'd write a connector class that knows how to query my server over a socket to make a request for specific data, which would return it to the model, and then to the controller, and out the door as a HttpResponse.
I'd appreciate some input on this design here. My company is transitioning from doing desktop software into SaaS, and as such, no one in the company knows how to do this stuff yet and me and a coworker are pioneering the way (we are currently working through options for getting some professional development so we can learn best practices and such).
Best Answer
Whether or not you can easily integrate a REST API on your current server depends on the architecture you have there, but you should be able to do it somehow. However, moving your existing project code to the REST project might be an easier solution if you're inexperienced with web development, because you'll be able to use an existing template for the web part.
Concerning
[devices] --> server <-- REST API <-- Webpage, REST API here just means an interface, the Webpage is communicating with the server directly in terms of physical client-server architecture, however it must use the REST interface (API routes) that you defined.REST APIin that graph isn't a physical part of the system, but just an interface.Finally, REST is just an architecture style for defining API routes, how a server can be accessed via HTTP requests. It is not linked to Entity Framework or even having a database, those are just used in tutorials because a REST server that communicates with a database is a common use case. You can write any code in your controllers to get the data for the website, including a call to another service and waiting for the result (which in a way is what you're doing when you're using Entity Framework - calling a database service). As a side note here, I suggest that you abstract your existing code somewhere and let the controllers access it via an interface to keep your controllers clean and short, and maintain a separation of concerns between different layers of the application.