API
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.
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.