I am interested in the thoughts on adding a new endpoint to the OpenVPMS package - currently our endpoints are 

Login servlet

app servlet

download servlet

and I think there is a logout servlet

I am wondering what everything thinks about adding a

 

api servlet.

 

The api serlvet would be an authenticated endpoint for data retrieval and submission into and out of the openvpms application framework.

I would propose it would recieve data as a a JSON post request across a https connection.

authentication could be performed a number of ways including the use of a secret api key string or a  user/pass system. 

The number of functions available to the api would be controlled and end user configurable.  However it would be extensible by development.

We are getting SO many integration requests It may make sense to make this sort of point of entry.  

Currently the ESCI interface is a "call out" interface only.  It makes a request and then recieves the response.  The api would act as a "call in" interface.

The HL7 sending and recieving interface could be extended but I can see instances where it isnt going to work it as HL7 documents are limited to providing certain actions and information.

Off the top of my head the as an example 

A web page could be created to allow a authenticated user to make a api request the could look at the available appointments for a certain timeslot.  The API would return the available slot or slots.  The user could select a slot and then post back to the api to "book" the appointment.

The construction of a webpage(php) and security of that system would be a third party or enduser responsibilty.  OpenVPMS would just need to provide means to authenticate a POST is from a verified address  and user.  

Other ideas:

    Clients access historical account data

    Clients access reminder data 

    Clients accessing pet information and data.

    

    

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: API

A general REST interface based on the archetype service is going to be too low level to be of much use to anyone. We would be better off providing REST interfaces to support specific functionality. 

Re: API

I guess I was sort of thinking about a extensible interface similar in the way JOBS are extensible.

 

Regards
 
Ben 
OpenVPMS Installer and Helper 
Ph: +61423044823 
Email: info[at]charltonit.com[dot]au
Syndicate content