Fuga provides a variety of REST APIs. This public wiki is intended to give an overview of the available APIs, some of them are public and some of them are (at the moment) for internal use only.


Authentication


Depending on the requirements for an API we provide the following authentication mechanisms:


  • Username/password
    • Form Based - Container managed (FB-CM): this is for endpoints used by the Fuga GUI and typically used by users with Role FUGAVET and FUGAASSISTENT
    • Basic Authentication (BA): this is for endpoints that are called by applications other than Fuga and which are not a browser. Communication must always happen over TLS and in case the communication consists of a sequence of calls a session should be established.
  • Token or Shared secret
    • As query parameter (QP): this is used to share information with third parties that don't have an account at Sonetas. This is typically used for short-lived access and should always be used over TLS.
    • As 'Bearer' in Http Authorization header (BER)


Every application using an API must also provide an applicationKey when it uses the API. The applicationKey must be set as a custom http header with name'X-Application-Key' and can be requested from Sonetas at fuga@sonetas.eu. Without valid applicationKey access will be denied.


Authorization


Via the rest service one can read and manipulate data by calling API endpoints (functional resource) from underlying databases (data resource):

  1. The functional resource is described by the 'Role' of the user. This determines which API endpoints can be called.
  2. The data resource is described by the 'Scope' (this is our definition, no relation with e.g. OAuth scopes), this describes to which (part of) databases (=practices) the user has access. Typical scopes are 'practice X', 'patient Y', 'all mypets practices', …


APIs


The below table gives an overview of the Fuga APIs. Each API can have multiple endpoints. The baseUrl in the table indicates the part that comes after https://(test.)sonetas.eu/fuga/


APIRolesAuthenticationSessionTypical scopeBaseUrlDescriptionUsed by TODO
FugaUiFUGAVET,FUGAASSISTANTFB_CMcookiepractice Xrestc/ui (rui)returns Fuga webpages (for this API the applicationKey can also be specified as sa queryParameter with name 'applicationKey')  voIP devices
mFugaFUGAVET,FUGAASSISTANTFB-CMcookiepractice Xrestc/mfuga2
mFuga2 and Nova agenda
SymphonyFUGASYMPHONYBAnopractice Xrest/symphonypost lab results and imagesSymphony clients in the practices
PetOwnerFUGAPETOWNERBAnopractice X,Y,Zrest/petownerapi for pet user appmypets app, wellopet
FugaShareFarmer/QPnoclient Xrest/myvetget info important for farmerFuga Share (farmer)

change path to rest/share


FugaShare/QPnopatient Xrest/share(temporarily) share object (file, history) with third party (e.g. colleague)
implemented for files. TODO add other objects
Control/BERno*rest/controlchange in-memory fields at runtimeinternal
InterFugaINTERFUGAFB-CMcookiepractice X,Y,Z,…restc/inter/{practiceId}Fuga User querying other Fuga practice
implement
SuperFugaReportingSUPERFUGAREPORTINGBAnopractice X,Y,Z,…rest/super/reportingread only: financial reports, statistics, db dump

SuperFugaConfigSUPERFUGACONFIGBA or FB?cookie (optional)practice X,Y,Z,…rest/super/configallows to set prices/conformance level, suggest acts/protocols/care plans for multiple practices

Shop - NOT IMPLEMENTEDFUGASHOPBA
practice X,Y,Z,…rest/shopallows to get product list, stock, find client based on e-mail, post order (can be used for practice catalog or for third-party catalogs)
SuperMyPetsMessagingSUPERMYPETSMESSAGINGBAnoall mypets practicesrest/super/mypetsallows to suggest mypets messages
implement


The picture below illustrates how the InterFuga and SuperFuga APIs are situated.



Concerto


Concerto is the application offered by Sonetas to manage multiple Fuga's. The principle is that Concerto makes all the functionality of the SuperFugaConfig API accessible via a GUI.


Some super-user groups want to be able to manage objects like species, breeds and sexes of multiple practices. The frequency of this type of change is expected to be so low that we believe it is not worth to create an API or GUI for this purpose and that these change requests should be handled via other channels (e.g. email and an sql script).