HTTP/REST Interface for Desktop APIs

The Problem

Web applications are cheaper to develop and cheaper to maintain, than desktop applications. Many tasks which were considered too heavy for the web in the past, are implemented with web technologies now. Microsoft Excel Online and Google Sheet for spreadsheets, Figma for graphics design.

I have worked in large enterprises most of my career. Many enterprise/business applications I have seen could be web-based, but were not, because they needed access to various desktop APIs. I'll focus on three use cases here.

Authentication, Authorization, Audit

Web-browsers give no direct access to authorization, authentication and audit APIs provided by operating systems. Windows workstations are usually joined to an Active Directory domain. Permissions are managed by group membership within the domain. Hundreds, if not thousands, of groups and policies are serving usual enterprise. Restricted logon hours, whitelisted logon workstations, centralized collection of audit log. Every desktop application may call a few simple APIs to check if current user has specific privilege, is a member of some specific group, just lists all current user groups, or writes an important message to the event log. But good luck integrating this with your new fancy web-based SaaS. No single sign-on for you, no event log. If infrastructure is hybrid and the cloud part is Azure, you may have some luck with SAML and Azure Active Directory, but if not, you most likely will be asked to install on-premises version or leave immediately.

Printing and imaging

Web-browsers provide no usable printing APIs. Printing is important, whether it is cheque, report or handout. Most websites just give up on printing and export PDFs. This experience is terrible, starting with color support and ending with A4/Letter confusion. If printing is an essential part of your application’s workflow, like for a cash desk, web technologies are simply unusable. Google Cloud Print is discontinued, so the situation will become even worse. Scanning with preview? I don't even know where to start. It's simply impossible.

Industrial devices

There are a lot of industrial hardware devices. None of them can be accessed from the browser, if not explicitly supported, like FIDO tokens. Most can be accessed via text-based protocols over serial ports. They are begging to be wrapped into web-sockets.

Why is it so bad?

There are two answers I know: First answer is “other priorities”. Web technologies are mostly for landing pages, not for business applications, so a new CSS selector is more welcome than industrial devices. Second answer is “security”. It is hard to introduce new features without introducing new attack vectors.

The Proposed Solution

Create a universal windows service application which will provide a highly secure, easy to use REST interface. Allow JavaScript applications to fully integrate into desktop environments. Security is paramount. Permissions, which website has access to what APIs, should be opt-in only, clear, managed by Administrators only and optionally by global Active Directory policies. Everything is double checked, secured, isolated and sandboxed if possible.