Currently, my thoughts are that GET requests would be feasible by using the concept of screen scraping combined with a cron job that runs at a set interval to scrape data from the GUI and sync to my own database.

However, I'm not quite sure how I would handle actions that seek to mutate the database that sits behind the GUI. I am quite certain I would need to interface directly with the GUI, but what tools are available that could help automate this by programmatically controlling the GUI?

Also, since an overall architecture such as this is far from conventional, I'm curious what strategies might be utilized to help scale a system such as this.

Note: It is acceptable for data returned from a GET request to be stale for at least as long as the cron job interval, and for POSTs and PUTs and the like to complete sometime in the future, let's say half an hour.

Note: Maybe my train of thought is completely idiotic and there's a better angle. I'd love to know.

  • 1
    Why not talk to the DB directly? Jan 4, 2019 at 2:07
  • 4
    All interactions with a DB must go through the GUI WHY? I seriously don't care how legacy, how 3rd party, how closed source, or even proprietary, unless you would actually be breaking the law to reverse engineer your own API (see Google vs Oracle) to talk to the DB I honestly think it's unprofessional not to. Jan 4, 2019 at 3:44
  • 2
    @J.Munson If the desktop app has a database, there's a reasonably good chance that it uses one of the well known embedded database systems (SQLite, local MSSQL, Berkeley DB, the old Jet engine from VB, dbase files, etc). The first thing I'd do is inspect the files and try to figure out what it is using. Jan 4, 2019 at 8:19
  • 2
    Are we down-voting this question, because it is a bad question, or because it is a bad idea? Bad ideas don't necessarily make bad questions. Jan 4, 2019 at 17:56
  • 1
    The original GUI application developer probably never thought that the database may be used by another application in the future or that the database may outlive the original application. Perhaps he or she completely encapsulated all database access behind a dozen layers, possibly using some fancy ORM library, so that "you can easily change the database in the future", ending up with all business logic and all integrity constraints in the application. If that's the case, then reverse engineering becomes very hard, and programmatically controlling the GUI may not be such a bad idea, after all. Jan 30, 2020 at 6:51

1 Answer 1


If you can programmatically click buttons and retrieve data from the GUI application then you can wrap that program in a REST service.

I have been in a similar situation and wrote a web service which entered a code and clicked a button to automate a program which required a user use a code card on the machine.

In my case I used IIS .net (or vb6? cant remember) and wrapped windows api calls.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.