Applicazione desktop basata su rest

La divisione dell'applicazione desktop in server e client non è così comune. Ma non è nemmeno inaudito. Linux X Server potrebbe essere un buon esempio di questo.

Il motivo per cui non viene usato più spesso, è che l'API tra client e server è molto rigida e severa. La domanda è se i vantaggi di tale approccio: esecuzione in un processo separato, possibilità di utilizzare linguaggi diversi, framework o approcci di sviluppo su entrambi i lati, maggiore sicurezza, ecc. L'inflessibilità totale derivante dalla separazione netta tra client e server. Nella maggior parte dei casi, questi vantaggi non sono sovrappesati. Ma in alcuni casi specifici potrebbe.

Nel tuo caso, potrebbe avere senso, poiché consentirebbe di sviluppare l'interfaccia utente in un sistema completamente separato rispetto alla libreria di calcolo. E mantenerli in processi separati potrebbe proteggerli da eventuali problemi di stabilità nell'altro lato.

Inoltre, smetterei di concentrarmi così tanto su "REST". Il problema principale qui è la separazione dell'interfaccia utente e della logica di background in processi separati. In che modo questi processi comunicano è secondario.

L'indipendenza dalla piattaforma della GUI non dipende dall'indipendenza della piattaforma dell'API della liberia, dipende dall'indipendenza della piattaforma dell'implementazione della GUI. E la tua GUI non sarà "indipendente dalla lingua", dovrai scegliere un linguaggio di programmazione per implementarlo.

Presumo che il tuo "linguaggio di programmazione di basso livello" in cui la lib è scritta fornisce già la classica API C? Quindi per una GUI, l'utilizzo di uno degli ecosistemi mainstream per lo sviluppo desktop che fornisce l'indipendenza dalla piattaforma (come Java o C ++ con un framework come Qt) vi permetterà immediatamente di includere la lib (in Java da JNI, in C ++ collegandolo direttamente ). Non è necessario creare uno strato REST intorno ad esso, che richiederebbe

• un ulteriore livello di rete per il client e il server
• per mappare l'API delle librerie artificialmente al paradigma CRUD di REST, anche se la tua lib non ha nulla in comune con le operazioni CRUD

L'uso di un livello REST, o forse un altro tipo di strato di comunicazione Web, ha senso solo se si desidera avere l'opzione di eseguire la GUI su una macchina diversa oltre al server in cui vengono eseguite le funzioni della libreria. Per un'applicazione desktop con una sola macchina, rende le cose troppo complicate.

REST è una nomenclatura web. Eppure stai prendendo di mira questo per eseguire localmente, con un'app desktop. Perché le soluzioni desktop consolidate non sono accettabili?

Non menzioni alcuna specifica tecnologia di implementazione a cui sei destinato (ad esempio .Net, Node.js, ecc.). Su Windows, ciò che stai descrivendo sarebbe in genere esposto come uno dei seguenti:

1. Un semplice riferimento alle DLL
2. Un componente COM + (ai vecchi tempi)
3. Un servizio con un endpoint esposto e un server Web incorporato
4. ** Un assembly registrato nel GAC e referenziato nella tua app desktop **