Web Services

EthosCE has a powerful RESTful webservice that can be used to send or retrieve information from an EthosCE website through HTTP requests.

The web service extension supports full CRUD (Create, Read, Update, Delete) for resources:

• Create: HTTP POST /<entity type name>

• Read: HTTP GET /<entity type name>/<entity id>.<format>

• Update: HTTP PUT /<entity type name>/<entity id>

• Delete: HTTP DELETE /<entity type name>/<entity id>

JSON and XML are the supported "formats" for sending and receiving data.

Contents

Authentication

All web service requests require login, before accepting a query. A separate login call is not required for authentication. Login credentials are sent via HTTP Basic Authentication headers, in the requests. An example of the structure in PHP is shown below. Note, that all calls require this login to function properly.

Creating a web service account

Follow the creating an account instructions and assign the “web service” role. Ensure the username begins with “restws.”

HTTP Basic Authentication in curl

Querying EthosCE

Clients may use GET calls, to pull information from the system, including applying advanced filters and sorting.  Reference the Web Service Data Structures page for more information on each content type, their available fields, and accepted values. Most fields, including custom, are available to filter against. Multiple filters may be added to the query string via ampersands. The examples below detail common URL filter configurations.

Supported Operators

Query Examples

Return all credit awarded to user 2, sorted by awarded date

Return all credit awarded after or on 08/20/2016 but before 08/21/2016

Return all credit awarded that is not AMA

Payload manipulation

The default for payload structure is to load the full field values for the first level of simple field types (text, select boxes, radio buttons, etc). More complex field types like the field collections (Profile Boards) or entity references (Course ACCME Data), will display a reference to that additional data type. Additionally, you can limit data returned to shrink returned payload size.

For more, please see Payload Manipulation.

Date Formatting

There are 2 date formats used when interacting with the web service, epoch and ISO 8601. The format used is dependent on what piece of data you wish to reference, usually either a property or a field. Additionally, both date formats must be converted to UTC before being sent, to ensure data integrity between systems.

Sending Date fields in queries

When using date fields as a parameter, the format must match the field you are referencing. As general guide, in courses, all added form fields, like custom fields, are formatted as ISO, and most date properties, like created and updated, are timestamps. Additionally, date fields with end dates require an added parameter to reference the correct date field.

Unix timestamp fields require an epoch timestamp format in the parameter, and are usually single date properties.

ISO date fields are more complex. They may have an End date, such as the expiration date in the Course Date field. These require an additional parameter to specify which of the two fields you would like to compare against, the start date (value) or the end date (value2).

Formatting an ISO date field with an end date i.e. Course Date (field_course_date), Event/Session date (field_course_event_date), or a custom form field
Course date Open: field_course_date[value][le]=2017-12-25
Course date Expiration: field_course_date[value2][le]=2017-12-25

Formatting an ISO date field without an end date i.e. Course Date (field_course_date), Event/Session date (field_course_event_date), or a custom form field
Custom: field_custom_date[value][le]=2017-12-25

Formatting a unix timestamp field for 2017-12-25 i.e. created and updated
created[ge]=1514160000

Error Returns

Errors are reported from the RESTful web service with HTTP codes:

• 404: Not Found

  • The resource was not found

• 403: Forbidden

  • The web service user does not have permission to use the resource. 

  • If this error is seen often, verify the session authentication step have been completed.

• 406: Not Acceptable

  • The data sent to the web service is not in an acceptable format or is missing required fields. Check the documentation for the correct fields and format.

• 200: OK

  • The web service call is successful. Data may or may not be returned depending on the operation.

• 201: Created

  • The web service call created data

Example Scenarios

The following examples of standard calls to EthosCE are written in PHP, in JSON, using the Curl library.

Additional Links