Cette section décrit l'API privée d'un site rEve, c'est-à-dire l'ensemble des services requérant une authentification. Les principes de base sont les mêmes que ceux de l'API publique, à l'exception des éléments détaillés ci-après.

Authentification

Les requêtes vers l'API privée seront effectuées via une authentification de type « Basic HTTP Authentication », via un login et un mot de passe.

Format de retour standardisé

La plupart des services injectant des données dans rEve retourne une réponse de succès ou d'erreur qui suit un format standardisé, dont voici une illustration.

<?xml version="1.0" encoding="utf-8" ?>
<Response type="object">
 <code type="int">0</code>
 <text>Success</text>
 <data/>
</Response>

Le tag principal d'une réponse standardisée sera toujours Response.

Ensuite, un code applicatif est fourni (sous-tag code). Il vaut 0 si l’appel au service n’a produit aucune erreur. Ce code applicatif, comme son nom l’indique, est un code lié à l’application et à sa fonctionnalité : il ne représente pas un code de retour HTTP.

Voici quelques considérations importantes.

• Si vous essayez d’accéder à un service alors que vous fournissez une combinaison login/mot de passe erronée, le service vous retournera un code HTTP de retour 403.
• Si vous appelez un service et qu’une erreur interne, non gérée, se produit dans HubSessions, vous recevrez un code HTTP de retour 500. Notez que ce sera le cas si, par exemple, vous omettez de typer un tag requérant un typage par HubSessions, telle une date, par exemple, qui ne disposerait pas de l’attribute type="DateTime".
• Si vous essayez d’appeler un service dont le nom est erroné, vous récupérerez un code de retour HTTP 404.
• Dans la plupart des autres cas, vous recevrez un code de retour 200. Alors que, dans les exemples précédents, il est en général inutile d’accéder au corps de la requête (sauf pour récupérer le détail de l’erreur sous la forme d’un message textuel en cas d’erreur 500), dans ce cas-ci, c’est opportun, et, au sein de ce corps, formaté en XML comme illustré ci-dessus, vous trouverez donc un code indiquant le succès ou l’échec de l’appel, en termes applicatifs.

Au-delà du code applicatif, un texte court (tag text) donnera plus de détails au sujet du succès ou de l’erreur éventuelle.

Si le service doit retourner des données spécifiques, celles-ci seront disponibles sous le tag data.

La page de détail d'un service vous précisera si le service en question fait usage de ce format de retour ou non, et si oui, quel est l'éventuel format détaillé du sous-tag data.

Le tableau suivant liste les types d’erreurs. Ils sont communs à l’ensemble des services les utilisant, car ils s’appliquent à la notion abstraite d’objet, dont les différents concepts de rEve sont des manifestations.

Services

Le tableau suivant liste les services disponibles. Un clic sur le nom d'un service vous emmènera sur sa page détaillée.

L’URL de base pour appeler chaque service sera notée <siteUrl>. L'URL complète d'un service se détermine en ajoutant le nom du service à cette URL de base. Par exemple le service "create/activity" a l'URL complète <siteUrl>/create/activity.