Call back API

This forum is for programmers who have questions about the source code.
Post Reply
SriramChellappan
Posts: 42
Joined: Thu Mar 11, 2021 2:45 pm

Call back API

Post by SriramChellappan » Tue Apr 13, 2021 12:02 pm

I understand the security risk of running API services in dental office servers. However is there a way cloud servers can register with the dental office servers, so that the communication can be initiated from the dental office servers.

The request could be waiting on the cloud server for the local server to pick up the request and send the information back to the cloud.

User avatar
jordansparks
Site Admin
Posts: 5739
Joined: Sun Jun 17, 2007 3:59 pm
Location: Salem, Oregon
Contact:

Re: Call back API

Post by jordansparks » Tue Apr 13, 2021 7:40 pm

I'm sorry, I don't understand. "register with the dental office servers"? You must be talking about some program running on the server. It sounds like you might be asking for specific program suggestions. I can't really think of any. It's totally possible, but I just don't know what program to suggest.
Jordan Sparks, DMD
http://www.opendental.com

SriramChellappan
Posts: 42
Joined: Thu Mar 11, 2021 2:45 pm

Re: Call back API

Post by SriramChellappan » Wed Apr 21, 2021 11:37 am

I am thinking along the lines of

the local server can provide a list of services that are available only for the registered cloud servers. The services do only one way data push. Example if a cloud server registers to receive any changes to patient, then the data will be pushed whenever there is a change to patient.

Taking it one step further the services can get the last time the cloud received and processed the information and provide changes from that time until now.

This architecture will not require any port to be opened in the local server and protect it from any hacks.

User avatar
jordansparks
Site Admin
Posts: 5739
Joined: Sun Jun 17, 2007 3:59 pm
Location: Salem, Oregon
Contact:

Re: Call back API

Post by jordansparks » Wed Apr 21, 2021 4:42 pm

Databases, by nature, are pull instead of push. That's why we use the signalod table to keep track of tables that have changed and need a new pull. The FHIR interface attempted some sort of push, but the new API will just be pull. There are a few other push paradigms that I can think of:
-replication
-mysql triggers?
Jordan Sparks, DMD
http://www.opendental.com

Post Reply