These docs are for the beta release of the ricloud v3 API. We will be making many improvements to both the API and these docs over the coming weeks.
No major changes to the API interface are planned, only the addition of new features.
Get in touch if you have any feedback. We’d love to hear it!
The is the documentation for the third version of Reincubate’s ricloud API. The API provides a mechanism for users to easily access app data from a variety of data sources, including Apple’s iCloud and local iTunes backup via asrelay.
Product information for ricloud is available on Reincubate’s site.
Before plunging into the getting started section, it is helpful to be familiar with a handful of terms and concepts that will be used throughout.
A service describes a collection of data sources available through the API. This includes third-party services, such as iCloud, or Reincubate products, such as asrelay.
Different services will have varying requirements for certain resources on the API, as well as alter the overall lifecycle of API objects. For example, the payload needed to create a session for the iCloud service differs from that needed on the asrelay service.
These are specific sources of data within a service. An iCloud account is the primary source of the iCloud service, whereas an asrelay client instance is the primary source of the asrelay service.
In many cases, a service will have a hierarchy of sources which can be targeted individually. For example, the iCloud service has account sources and device sources.
A user should always represent the end-user that is requesting data. In many cases, this will be a user of your application.
A session represents access to a specific source, and is needed in order to retrieve any information or data from the source through the API.
Creating a session is the equivalent of a ‘login’ into an iCloud account or ‘pairing’ with an asrelay client instance.
The API will execute the session initialisation process asynchronously via a task. This means the call to create a session will return immediately, but the session will not be ready to use until initialisation is completed.
Polls are how users can request data through the API. An active session against the targeted source is needed for a poll to be setup.
All polls are processed asynchronously via one or more tasks, and results are published to cloud storage buckets configured on your organisation.
These are the underlying chunks of work performed by the API. When a session is created, it also creates a task in order to perform any initialisation against external services. When a poll is created, it will create at least one task to perform the data retrieval work.
The API is organised around a set of resources described in the API resource reference. Through these resources, a client of the API is able to: customise their API configuration, initialise access to data source, and retrieve data from these sources.
The API relies on asynchronous operations for setting up sessions against third-party services and data processing. This gives it the ability to manage a large amount of data demand while interacting with external services responsibly. It also affords extra flexibility to react to fluctuations in response times or degradation in services from third parties.
Storage bucket publishing
Data requested from the API is published directly into a client’s bucket on either Google Cloud Storage or Amazon S3. This helps to minimise issues related to scaling data delivery, and also enables faster data retrieval as publishing is less likely to become a bottleneck.
Notification of asynchronous operation completion is handled via a webhook mechanism, whereby events are sent to a client’s server through standard HTTP requests. These events contain information on where to find requested data within a client’s bucket, allowing the client to make a decision on when and how to use it.