Lead (lea)Document (sdoc)

In interacting with the Synapcus APIs you will interact with entities and their specifical fields. Here you find a description of the main Synapcus entities and the concepts behind. 

Convention over configuration

All the Synapcus entities, views and API calls underlay the paradigm of convention over configuration. So if you understand the Synapcus naming conventions, you are able to configure and programm the API's quicker and more efficiently. 

Programming Levels

In the Synapcus programming ecosystem there are 3 important levels:

The database level

Here we work mainly with forms (like i.e. "prj"), documents and fields (''prj_name"). The documents are organized  in views like i.e. "vwPrjs".

The QEE classes level 

Here we work with Synapcus classes (like i.e. "QEEPrj" which access class properties like "prj_name").

The REST level

Here we work with RESTful APIs (GET, POST, PUT, DELETE) like i.e. "POST xrPrj" which access JSON structures containing properties like "prj_name". Sets of data can be manipulates with the pluralized calls like i.e. "xrPrjs".

JSON requests and responses

The REST responses will use these entities to format the resulting JSON.

You can intuitively build field names based on the entity names (i.e. perprj_per_unid will represent the unique ID for the connection from perprj to prj).

Base entity

All the Synapcus entities inherit from the virtual base entity QEEObject (prefix "qee_"). This base entity defines the basic fields like: 

  • form: entity short name (i.e. "prj" for project)
  • qee_unid: unique id for this entity (32 Bytes, i.e. "CB38065334B93C03C12579DF004495D1")
  • qee_waste - if "1" the entity was deleted and is in trash
  • qee_categories - general tags for the entity (i.e. "for-me")
  • qee_readers - reader names for the enetity
  • qee_readers_type - predefined sets of reader names (i.e. "all")

Common entities

The most common used entities which you deal with in using the Synapcus API are: