Nie sądzę, że REST API jest najlepszym rozwiązaniem. Jeśli będziesz tym zarządzał technikami devops to może i tak, ale to i tak overkill. Jeśli ma to być aplikacja standalone to główna aplikacja powinna uruchomić drugą aplikacje i dbać o to, żeby proces tej drugiej żył/odpalał ponownie w trakcie krachu. Dalej komunikować się z nią, ale HTTP czy TCP nawet localhost to overkill, więc najlepiej po plikach.... albo - named pipe. No więc trzeba by opracować jakiś protokół client-serwer na named pipe i razem z zarządzaniem procesem podrzędnym ma się sposób komunikacji 2 aplikacji - teraz można przygotować do tego klasę API i gotowe!
Na szczęście MS wpadł na to wcześniej i zaimplementował to za nas. Technologia ta nazywa się COM+ DLL Surogate i w prosty sposób można łączyć aplikacje między różnymi dotnetami, a nawet miedzy różnymi językami czy nawet architekturami (32/64bit) i w eksrremalnych przykładach, nawet maszynami tworząc system rozproszony, napisany jak standalone. Tego ostatniego nie polecam, jednak architektura microserwisów jest lepsza, natomiast do takiego żenienia legacy i nowych rzeczy pasuje jak ulał. Jest to szeroko stosowane, ale diabelnie źle udokumentowane, natomiast da się. Znam wiele takich zastosowań w biznesie dużych korporacji - natomiast zazwyczaj ktoś kogoś tego uczy, lub ktoś uczy się ze skrawków nowych oraz legacy dokumentacji i zachowuje tą wiedzę dla siebie.
W praktyce jak przygotować poprawnie obiekt COM, oraz poprawnie w kodzie zadbać o jego rejestracje w rejestrze windows, i ew. reagowanie jak taki obiekt COM już jest zarejestrowany, to końcowo dla programisty użycie takiego obiektu nie różni się niczym. Tworzy się obiekt, przez new i w momencie wołania jakiejś metody czy property następuje komunikacja po named pipe, ale to jest ukryte dla nas i takie wywołanie nie różni się niczym od wywołania obiektu istniejącego w pamieci głównego procesu.