Difference between revisions of "Internal GCAPI"

From GrandCare Systems
Jump to navigation Jump to search
Line 56: Line 56:
See [[History API Subsystem]] for details
See [[History API Subsystem]] for details


== Assign API ==
== TODO ==
* URL: $SystemAddress/api/assign.php
* assign api
 
* caregiver api
== Caregiver API ==
* carenote api
* URL: $SystemAddress/api/caregiver.php
* configure api
 
* device api
== Care note API ==
* <strike>history api</strike>
* URL: $SystemAddress/api/carenote.php
* log api
 
* media api
== Configure API ==
* medication api
* URL: $SystemAddress/api/configure.php
* message api
 
* pin api
== Device API ==
* resident api
* URL: $SystemAddress/api/device.php
* rule api
 
* system api
== Log API ==
* URL: $SystemAddress/api/log.php
 
== Media API ==
* URL: $SystemAddress/api/media.php
 
== Medication API ==
* URL: $SystemAddress/api/medication.php
 
== Message API ==
* URL: $SystemAddress/api/message.php
 
== PIN API ==
* URL: $SystemAddress/api/pin.php
 
== Resident API ==
* URL: $SystemAddress/api/resident.php
 
== Rule API ==
* URL: $SystemAddress/api/rule.php
 
== System API ==
* URL: $SystemAddress/api/system.php
 
= Other Resources =
= Other Resources =
* [https://github.com/ngharo/gc-javascript-api Experimental JavaScript library]
* [https://github.com/ngharo/gc-javascript-api Experimental JavaScript library]

Revision as of 20:01, 2 August 2012

GCAPI gives developers access to the core tools provided by a GCManage server and como systems. A variety of tasks can be performed by making simple web service calls.

Calling GCAPI

A basic call to GCAPI looks like this:

http://[como-URL]/api/[api-subsystem].php?passcode=[my-passcode]&op=[operation]&encoding=[json|xml]

The como URL and passcode are from the results of a GCManage API remote login call. The como URL is what GCManage determines is the path to the como system. This can either be proxied or the direct IP of the system. passcode is the authentication mechanism used by GCAPI -- it is a code generated every 24 hours by a system and reported to GCManage. subsystem names the subsystem you want to work on and operation defines the actual operation to perform. Each operation can have a number of other parameters that will be passed via other parameters in the URL.

Local Application Authentication

Applications may also want to call the API without an associated GCManage account. GrandCare will provide each application an "application key" that allows for a simple way to fetch the required passcodes. To do this, call the API via "localhost" using the following URL:

http://[como-URL]/api/system.php?op=getpasscodes&appkey=[gc-provided-app-key]

This will return the required passcodes for making authenticated calls to the API. See the section on the System API Subsystem for more information about the getpasscodes API call.

Results From GCAPI

The response from GCAPI will either be encoded in JSON or XML, depending on the requested encoding. By default the response will be encoded in XML.

XML Results

By default, GCAPI responds to commands by returning an XML document. Here is the most basic success result:

<gcapi>
   <result>SUCCESS</result>
</gcapi>

The root XML element for all GCAPI results is gcapi. The other always present element is result, which contains either SUCCESS or FAILURE, depending on whether the call succeeded or not. A failure response also contains the fail-message element, which gives the reasons for the failure. For example:

<gcapi>
   <result>FAILURE</result>
   <fail-message>Invalid credentials for API call</fail-message>
</gcapi>

This result would occur if invalid credentials were supplied during the GCAPI call.

JSON Results

GCAPI can also respond by returning a JSON object. Here is the most basic success result:

{
   "gcapi": {
       "result": "SUCCESS"
   }
}

A failure encoded in JSON looks like:

{
   "gcapi": {
       "result": "FAILURE",
       "fail-message": "Invalid credentials for API call"
   }
}

API Subsystems

History API

The History subsystem allows you to fetch ADL and wellness data from a system. Most of the operations take the same parameters and return different data.

See History API Subsystem for details

TODO

  • assign api
  • caregiver api
  • carenote api
  • configure api
  • device api
  • history api
  • log api
  • media api
  • medication api
  • message api
  • pin api
  • resident api
  • rule api
  • system api

Other Resources