A RESTful API for internal company system accessing peripheral devices

Question

I am currently working on an internal storehouse management system for a certain company. They wanted it to be a web app so that they can use it without installation on any devices.

We decided to develop the system with .net core REST API as back-end and Angular web app as a front, since we are familiar with both.

The question is: the client needs the users to be able to access external devices, such as network printers and photo cameras for flaw detection. We have code to use them, handle parallelism, etc. However, most guidelines for developing RESTful APIs are not meant for internal company applications.

Off the top of my head I just made GET or POST controllers, I pass whatever details needed form the front-end and return an Image or a device response status. Like this:

// GET api/cameras/1
[HttpGet("{deviceId}")]
public async Task<IActionResult> RetrieveFrontImage(int deviceId)
{
    Image img = _remoteCameras.GetImage(deviceId);

    var stream = new MemoryStream();
    img.Save(stream, System.Drawing.Imaging.ImageFormat.Png);
    stream.Seek(0, SeekOrigin.Begin);
    return File(stream, "image/jpeg");
}

Is this a good practice? Can I do it better? Are there any guidelines for developing internal applications in the shape of web apps? Thank you for your advises.

Answer 1

There are two aspects: how to handle device access in a RESTful environment, and how to deal with internal versus public services.

I don't see any big issues with the first aspect, of course you can represent hardware devices as resources. Webcams have been available since long before RESTful was incepted, so you might implement access differently, but then you'd need to duplicate the authorization bits which seems error-prone and wasteful. Dito for printer access. The resources aren't all that interesting in that no significant representational state transfers happen, one kind just returns images (remember to add a Cache-Control: no-cache header), the other just accepts POST requests with probably very limited persistency (a print job might be created, whose success status is available only some time later), but I'm not aware of any rule that says resources must have a minimum access complexity to be deemed REST-worthy.

Second, whether an API is meant for public use or for internal use should not matter much, of course you will make access to devices depend on proper authorization, but that is true for many services which give access to non-hardware resources, too.