API & Docs | Chino.io

Object Model

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

The following object model diagram shows which resources can be managed through the Chino.io API and how they are interrelated.

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, and at solving unpredictable issues without creating lock-ins.

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 describes the Document structure or content (i.e. list of fields). Chino.io requires an explicit Schema definition to implement content verification and data indexing. By indexing a field, you can run extremely fast search operations over Documents, which will still remain encrypted.

show code sample

Document

A Document contains the actual data in JSON format. Each Document is associated with 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 to a 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. You can use the same set of basic types to define the fields of Document Schema and UserSchema.

show code sample

User

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

show code sample

Group

A 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 resource (Repositories, Schemas, Documents, UserSchemas).

A Permission is defined on a single resource or on its children (e.g. a user can have updated 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 used within the Basic Auth method by administrators or in a server-to-server integration. They should never be used within client-side applications (neither in compiled nor non-compiled code).

Application and Session Tokens

Following the standard OAuth 2.0 protocol, Users can log in via Chino.io API. As required by OAuth 2.0, an Application (secrets and ids) must be specified. The Chino.io API will return a Session Token (Bearer) which can be used for follow-up 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.