API & Docs | Chino.io

Object Model

Chino.io follows RESTful approach on defining Resourses and their management (creation, access, update, and deletion).

The following object model diagram shows which resources you can manage through the Chino.io API and what are their relations.

Data

Chino.io's API implements a noSql document-oriented database such as MongoDB. We aim at reusing standards and concepts that are familiar to developers, that do not create lockins, and that solve issues.

Repository

A Repository is used to organize data. Conceptually it is similar to a DB Schema in SQL jargon. A Repository can belong only to one Customer (account).

show code sample

Schema

A Schema is used to describe the Document structure or content (i.e. list of fields). Chino.io requires explicit Schema definition in order to implement content verification and data indexing. If you index a field tou can perform extremely fast search operations over Documents, even tough Documents will be always encrypted.

show code sample

Document

Contains the actual data in JSON format. Each Document is associated to a Schema. Document fields can be Integer, Float, String, Text, Boolean, Date, Time, DateTime (ISO 8601), JSON, Base64, BLOB. A BLOB field is a link to an attachement (see next div) that can contain any data representation (e.g. XML, HL7 or binary data).

show code sample

BLOB

BLOB is used to store large binary content such as ECG or X-Ray files. To facilitate BLOB storage and retrieval, each BLOB is assigned to a Document field. In this way the Document can contain metadata about the actual binary content that you can search and retrieve/download.

The loading of BLOBs is implemented via a chunk-based upload, which makes it easy to upload large files even from low-connectivity devices.

show code sample

Collection

A Collection is a way to group documents. A Collection can group documents of different types (having different Schemas). A Collection is used to implement an easy access set of documents, e.g., all documents of a specific user.

show code sample

Users

With Users developers can register, authenticate, and manage permissions to Documents and other resources.

UserSchema

Similarly to the Schema for Documents, the UserSchema is used to describe the content (i.e. fields) of a User object. It uses the same set of basic types that can be used for fields.

show code sample

User

The User represents the end-user of an app. The User is associated to a UserSchema and it stores the defined fields/data. It is used also to implement authentication (OAuth 2.0) and access control policies (Permissions) to resources (Repositories, Schemas, Documents, UserSchema).

show code sample

Group

Is used to group a set of users and facilitate the Permissions definition on resources. Users can belong to multiple groups. All Permissions will be evaluated to find at least one that allows a User to perform a requested action.

show code sample

Permissions

Permissions provide a very granular, yet simple, method to define CRUDA (Create, Read, Update, Delete, Administer) access control policies for Users (or Groups) on a resources (Repositories, Schemas, Documents, UserSchemas).

A Permission is defined on single resource or on it's children (e.g. A user can have Update rights on a Schema or on the Documents related to that Schema).

A Permission has two elements (check code sample):

  • Manage: defines what a User (or Group) can do on a resource (or its children).

  • Authorize: defines which permissions a User (or Group) can transfer to another User (or Group) for a specific resource (or its children)

Check the full API documentation for more examples

show code sample

Authentication

CustomerId and CustomerKey

These are the access keys that are used within the Basic Auth method by administrators or in a server-to-server integration. These keys should be never used within client-side applications (either in compiled and non-compiled code).

Application and Session Tokens

Following the standard OAuth 2.0 protocol Users can log in via Chino.io API. As mandated by OAuth 2.0 an Application (secrets and ids) must be specified. The Chino.io API will return a Session Token (Bearer) wich can be used for followup API calls. Once expired the token needs to be renewed.

Note that with Chino.io API developers could use OAuth 2.0 protocol in both 2-ledged and 3-ledged ways to implement both standard client-server authentication and the "OAuth as a Service" mechanism in which Chino.io is the identity provider for multiple applications that log in.