Guide du développeur

Utilisez les APIs de Kiubi pour ajouter de nouvelles applications à la plateforme

L’"API Publique Front-office", ou API PFO, permet aux développeurs front-end de créer de nouvelles interactions avec leur site par l’utilisation d’une API sous forme de Web service. Le but est d’ouvrir un accès dédié et structuré entre un client web (navigateur) et Kiubi.

Chaque site dispose de son point d’accès permettant aux internautes d’accéder aux données du site stockées sur Kiubi. Ces points d’accès sont publics dans le sens où il n’y a pas de restrictions d’accès si l’API est activée sur le site.

Activer l'API PFO

L’API est désactivée par défaut sur les sites de la Plateforme. Pour l’activer, allez dans les préférences du Back-office et mettez le bouton radio "Activer l’API" à "Oui".

Une fois l’API activée, cliquez sur le lien "Accéder à l'API Sandbox".
Le Sandbox est une vue fonctionnelle et documentée de toutes les fonctions disponibles via l’API PFO du site. Chaque site dispose de son propre Sandbox.Toutes les fonctions sont regroupées thématiquement (blog, cms, catalogue, panier, ...). Chaque fonction est ensuite détaillée : description, URL, arguments attendus, contenu attendu de la réponse, codes erreurs possibles. Un bouton "Tester" permet de créer une requête vers l’API du site et de récupérer toute les données de la réponse.


Ecran du Sandbox

Le Sandbox est à la fois la documentation de l’API et aussi un outil de prototypage pour vos développements.

L’accès au Sandbox n’est pas public, il n’est accessible qu’à un utilisateur connecté au préalable au Back-office. Si vous tentez d'accéder au Sandbox sans être connecté, vous serez redirigé sur la page de connexion du Back-office.

Pour un premier test, récupérons la liste des billets du blog. Pour cela, cliquer sur le lien "/blog" qui contient tous les points d’entrée relatifs au blog. Cliquer sur "GET /blog/posts.json" pour utiliser ce point d’entrée.


Point d’entrée /blog/posts.json

Cliquez sur le bouton "Tester". Le sandbox va alors exécuter une requête à l’API du site et afficher le retour au format JSON dans le champ texte Response Body. Toutes les informations propres à la réponse comme les entêtes HTTP et le code HTTP sont également affichées. Le champ Request URL indique l’adresse de la requête qui a été utilisée. Les billets du blogs sont listés dans le nœud data de la réponse.

Une réponse contient toujours les nœuds suivants :
  • meta : informations sur la réponse elle même
  • error : erreurs éventuelles
  • data : données de la réponse


Exemple de réponse

Intéragir avec sa session

L’API partage la même session que le visiteur du site. Il en découle que l’API permet par exemple d’authentifier directement un internaute ou de modifier son panier. Prenons justement le cas de l’ajout d’un produit à votre panier. Pour cela, assurez vous d’utiliser l’API d’un site e-commerce et d’avoir au moins un produit en stock dans votre catalogue. Utilisons l’API pour trouver l’identifiant de la variante de produit qu’on va ajouter au panier.

Pour cela, dépliez le point d’entrée "GET /catalog/product.json". Ce point d’entrée permet de lister les produits du catalogue. Afin de rajouter les informations concernant les variantes de ces produits, il faut utiliser le paramètre extra_fields. Cherchez le champ extra_fields dans les paramètres du point d’entrée et cliquez sur le lien variants. Le champ texte se remplit avec la chaine variants.

Paramétrage du champ extra_fields

Cliquez sur "Tester" pour lancer la requête. La liste des produits va s’afficher dans le champ Response Body. Explorer la liste jusqu’à trouver le tableau des variantes d’un produit (attribut variants) et noter la valeur du champ id.

Identification de la variante n°262 !

Ouvrez le point d’entrée "PUT /cart/items/{variant_id}.json", saisissez l’identifiant de la variante dans le champ variant_id/ puis cliquez sur "Tester".


Ajout d’une variante au panier

La réponse à cette requête contient dans le noeud data.summary un résumé de ce qui s’est passé (ici l’ajout avec succès de la variante au panier). Le nœud data.cart contient toutes les informations du panier (liste des produits, adresse et frais de livraison,...).

Résultat

Rendez-vous maintenant sur le site et vérifiez que votre panier contient bien ce produit !

Intégration de l'API au site

Nous fournissons un client JavaScript, utilisant le framework jQuery, pour vous connecter à l’API PFO. Les sources et la documentation du client sont disponibles sur GitHub à l’adresse suivante :
Pour les intégrateurs, nous fournissons également une version minifiée et numérotée, directement utilisable, à l’adresse suivante :
Le plugin requiert à minima la version 1.8.2 de jQuery. Pour intégrer le client à votre site, ajoutez les balises suivantes à vos pages :

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.8.2/jquery.min.js"></script>
<script type="text/javascript" src="{cdn}/js/kiubi.api.pfo.jquery-1.0.min.js"></script>

Exemple d'intégration sur "Shiroi"

Nous allons maintenant modifier un site en partant du thème graphique "Shiroi", disponible par défaut sur Kiubi. Ce thème intègre déjà la version 1.8.2 de jQuery. Nous allons ajouter un formulaire d’identification qui utilise l’API et récupérer quelques informations sur le visiteur connecté.

Editer les templates du thème :
  • fr/templates/1_colonne/index.html
  • fr/templates/2_colonnes_droite/index.html
  • fr/templates/2_colonnes_gauche/index.html
Y inclure le fichier javascript suivant, après l’inclusion du script "js.js" dans le head :

<script type="text/javascript" src="{racine}/{theme}/{lg}/templates/js.js"></script>
<script type="text/javascript" src="{cdn}/js/kiubi.api.jquery-1.0.min.js"></script>

Le formulaire d’identification sera placé dans le widget panier, situé dans l’entête de toutes les pages. On va y ajouter des champs login et mot de passe pour permettre à l’utilisateur de s’identifier sur le site tout en restant sur la même page.

Pour cela, éditez le template du widget panier theme/fr/widgets/commandes/panier/index.html.

<!--
Template du Widget "Panier"
-->

<!-- BEGIN:main -->
<div class="panier">
<!-- BEGIN:nonidentifie -->
<p class="login"><a id="api-link-login" href="/compte/">Se connecter</a>
  <span style="display:none;"> :
   <label for="api-login">Identifiant : </label>
   <input type="text" class="field" id="api-login" size="10"/>
   <label for="api-pwd">Mot de passe : </label>
   <input type="password" class="field" id="api-pwd" size="10"/>
   <input id="api-submit" type="button" class="submit" style="padding:3px;" value="Ok" />
  </span>
</p>

<script type="text/javascript">
  $(function(){
   // Interception du clic sur le lien "Se connecter"
   // et affichage du mini formulaire de connexion
   $(document).on('click', '#api-link-login', function(){
    $('p.login > span').toggle();
    return false;
   });


   // Login sur le click du bouton du mini formulaire
   $(document).on('click', "#api-submit", function(){
    var login = $("#api-login").val();
    var pwd = $("#api-pwd").val();
   

    // Pas de requête si aucun login ou aucun mot de passe
    if(login == '' || pwd == '') {
     $("p.login input.field").css('border', '2px solid red');
     return;
    }
 

    // Connexion à kiubi
    var query = kiubi.login(login, pwd);
 

    // En cas de connexion réussie
    query.done(function(meta, data){
     $(".login").hide().after('<p class="compte"><a href="/compte/">'+data.firstname+' '+data.lastname+'</a> - <a id="api-link-logout" href="/compte/logout.html">D&eacute;connexion</a></p>');
   

     // Récupération des commandes de l'utilisateur
     kiubi.users.getOrders(data.user_id).done(function(meta, data){
      if(data.length) {
       $('p.compte > a:first').before('Etat de votre dernière commande : '+data[0].status+' - ');
      }
     });
    });

   
    // En cas de connexion échouée
    query.fail(function(meta, error, data){
     $("p.login input.field").css('border', '2px solid red');
    });    
   });
 

   // interception du clic sur le lien "Déconnexion"
   $(document).on('click', '#api-link-logout', function(){
   

    // Déconnexion de l'utilisateur courant
    kiubi.logout().done(function(meta, data){
     $("p.compte").hide();
     $("p.login").show();
     $("p.login span").hide();
     $("p.login input.field").removeAttr('style');
     $("#api-pwd").val('');
    });
    return false;
   });
  });
</script>
<!-- END:nonidentifie -->

<!-- BEGIN:identifie -->
<p class="compte"><a href="/compte/">{prenom} {nom}</a> - <a href="/compte/logout.html">D&eacute;connexion</a></p>
<!-- END:identifie -->

<p class="panier_link"><a href="/ecommerce/panier.html" title="Détail du panier">{nb_produits} article{pluriel_produits} - {total}</a></p>
</div>
<!-- END:main -->
Seuls les internautes non identifiés sur le site voient un lien "Se connecter" dans l’entête car ce lien se trouve dans se trouve dans le bloc nonidentifie. S’ils cliquent dessus, les champs identifiant et mot de passe apparaissent.

Le clic sur le bouton "Ok" va appeler la méthode login du plugin qui va utiliser l’API pour vérifier le couple identifiant et mot de passe et connecter l’internaute. Si l’identification échoue, les champs identifiant et mot de passe sont entourés de rouge.

Si elle réussit, une deuxième requête vers l’API est lancée via la méthode users.getOrders du plugin pour récupérer la liste des dernières commandes de l’internaute. Si l’internaute a au moins une commande, on affiche son état dans l’entête.

Schéma

Tous les accès se font grâce à HTTP, via le nom de domaine principal du site (ex : monsite.kiubi-web.com/api/v1/).

$ curl -i http://monsite.kiubi-web.com/api/v1/blog/posts.json


HTTP/1.1 200 OK
Date: Tue, 30 Jul 2013 08:25:32 GMT
Server: Apache
Content-Type: application/json
Connection: keep-alive
Status: 200 OK
Content-Length: 5
Cache-Control: max-age=0, private, must-revalidate


[]

Encodage de caractères

Le charset supporté par les requêtes est l’UTF-8.

Paramètres

Utilisation des paramètres

Les méthodes de l’Api supportent pour la plupart des paramètres optionnels. Pour les requêtes GET, ces paramètres sont à reporter dans l’url. Par exemple :

$ curl -i "http://monsite.kiubi-web.com/api/v1/blog/posts.json?sort=comments_count"
Pour les requêtes POST, les paramètres non inclus dans l’URL peuvent être passés dans le corps de la requête. Ils devront être encodés selon la RFC 1738 et l’entête de la requête devra contenir un Content-Type à application/x-www-form-urlencoded. Par exemple :

$ curl -i -d "email=test%40example.org" "http://monsite.kiubi-web.com/api/v1/newsletter.json"

Paramètres courants

Les paramètres suivants sont utilisés très largement dans l’API et ont un fonctionnement homogène.

Paramètre Description Valeurs
extra_fields Ce paramètre permet d’augmenter le périmètre d’une réponse en ajoutant des informations complémentaires. Liste d’options séparées par des virgules
sort Ordre de tri des résultats de la réponse. Critère de tri. Pour utiliser le même critère mais décroissant, préfixer avec le caractère " - "
limit, page Paramètres de contrôle de la pagination des réponses. Cf : section Pagination

Paramètres optionnels de confidentialité

Les paramètres suivants sont communs à toutes les méthodes de l’API. Elles permettent d’adapter le fonctionnement de l’API à des clients n’implémentant pas tout le protocole HTTP ou avec des contraintes trop importantes pour le développeur.

Paramètre Description Valeurs
method Pour les clients ne supportant pas toutes les méthodes HTTP, il est possible d’utiliser le paramètre "method" pour simuler l’utilisation d’une méthode.

Un requête GET avec un paramètre method=PUT sera donc considéré par l’API comme une requête PUT.
GET, POST, PUT ou  DELETE
callback Nom du callback pour obtenir une réponse au format json-p. Chaine de caractères
suppress_response_code Si ce paramètre est à "true", l’API désactive l’utilisation sémantique des codes HTTP. Toutes les requêtes renverront en entête un code HTTP 200 OK. Le code HTTP initialement prévu reste néanmoins lisible dans le corps de la réponse.
 
Le bon ou mauvais déroulement d’une requête devra donc être manuellement vérifiée dans les messages contenus dans le corps de la requête.
 
Seule une indisponibilité technique de l’API peut tout de même retourner une erreur de type 500.
"true" ou "false". Par défaut à "false"
 
force_response_mime Si ce paramètre est renseigné, le mime/type par défaut application/json du format de sortie sera substitué par cette valeur.  text/plain
text/html

Schéma

Le corps des réponses respecte une structure commune. Une réponse simple peut être la suivante :

$ curl -i http://monsite.kiubi-web.com/api/v1/blog/categories.json


HTTP/1.1 200 OK
Server: Apache
Date: Tue, 30 Jul 2013 08:25:32 GMT
Content-Type: application/json
Connection: keep-alive
Status: 200 OK
Content-Length: 172
Cache-Control: max-age=0, private, must-revalidate


{
  "meta": {
    "success": true,
    "status_code": 200,
    "link": [],
    "rate_limit": 120,
    "rate_remaining": 120
  },
  "error": [],
  "data": [
    {
      "id": 1,
      "title": "Générale",
      "posts_count": 1,
      "slug": "Generale",
      "url": "/blog/Generale/"
    }
  ]
}
Le corps de la réponse est constitué d’un objet meta qui contient des informations relatives à la requête et un objet data qui contient les données qu’on souhaite récupérer. Son contenu est propre à chaque méthode de l’API.

Description de META

Paramètre Description Toujours présent Valeur
meta.succes Renseigne sur le succès ou l’échec de l’appel. A la moindre erreur, le paramètre est à "false". Oui "true" ou "false"
meta.status_code Code HTTP de la réponse. Si le paramètre suppress_response_code a été utilisé dans la requête, le développeur trouvera ici le code HTTP initial de la réponse. Oui Code HTTP sur 3 chiffres.
meta.link Groupe de liens hypermédias.  Explicite les interactions possibles avec la réponse. L’utilisation la plus courante est la pagination des résultats. Oui (peut être vide) Liste d’URL
meta.rate_limit Quota maximum de requêtes. Oui Entier
meta.rate_remaining Nombre de requêtes restantes. Oui Entier

En cas d’erreur la propriété meta.succes est à false. La réponse contient alors des paramètres supplémentaires. Un exemple de réponse avec erreur est :

$ curl -i http://monsite.kiubi-web.com /api/v1/blog/posts/9999.json


HTTP/1.1 200 OK
Server: Apache
Date: Tue, 30 Jul 2013 08:25:32 GMT
Content-Type: application/json; charset=iso-8859-1
Connection: keep-alive
Status: 200 OK
Content-Length: 5
Cache-Control: max-age=0, private, must-revalidate


{
  "meta": {
    "success": false,
    "status_code": 404,
    "link": [],
    "rate_limit": 120,
    "rate_remaining": 120
  },
  "error": {
    "code": 4401,
    "message": "Le billet n'existe pas",
    "help": "",
    "fields": []
  },
  "data": null
}
Une réponse d’erreur contient des paramètres d’erreurs supplémentaires.

Description de ERROR

Paramètre Description Toujours présent
EN CAS d’ERREUR
Valeur
error.code Numéro de l’erreur rencontrée Oui Entier
error.message Message d’erreur global. Typiquement une phrase. Oui Chaine de caractères
error.help Lien vers une page de l’aide permettant de résoudre l’erreur Oui URL
error.fields Liste détaillée des erreurs. Oui Tableau
error.fields.[n].message Message d’erreur Oui Chaine de caractères
error.fields.[n].field Paramètre de la requête à l’origine de l’erreur Oui Chaine de caractères
error.fields.[n].extra Eventuelles précisions sur l’erreur. Non Variable

Codes HTTP

Code HTTP Signification
200 La requête s’est bien déroulée
301 Redirection permanente
302 Redirection temporaire
304 Ressource non modifiée depuis la dernière requête
400 La syntaxe de la requête est erronée
403 Accès refusé
404 Ressource non trouvée
405 Méthode HTTP non autorisée
413 Requête trop volumineuse
500 Erreur interne du serveur
503 Service temporairement indisponible ou en maintenance

Encodage de caractères

Les caractères non ASCII sont transmis sous leur forme unicode (\uXXXX). Cet encodage est notamment compris nativement par javascript, quel que soit le charset de la page dans laquelle l’API est utilisée.

L'encodage à utiliser pour l'envoi de donnée vers l'API est l'UTF-8. En cas d'erreur d'encodage, l'API renvoie une erreur "Caractère non autorisé" et un code HTTP 400

Format des dates

Toutes les dates sont retournées aux formats :
  • date au format DD/MM/YYYY
  • date au format YYYY-MM-DD
Toutes les dates horodatées sont retournées aux formats :
  • UNIX timestamp
  • date au format DD/MM/YYYY HHh MM
  • date au format YYYY-MM-DD HH:MM:SS

Format de retour

L’API supporte le format JSON. Le format de retour est précisé lors dans l’URL de la requête par l’extension indiquée (.json).

Sans extension, le format de la réponse est par défaut le JSON. Le format de réponse est également reprécisé dans l’entête Content-Type (application/json).

Pour des besoins de rétrocompatibilité, le Content-Type peut être forcé à text/plain ou text/html, à l’aide du paramètre force_response_mime.
Les points d’entrée privés se basent sur une authentification par Cookie. L’API partage la même session que le visiteur du site. Il en découle que l’API permet d’authentifier directement un internaute, et qu’un internaute connecté au Front-office a accès directement à ses données via l’API :

$ curl -i http://monsite.kiubi-web.com/api/v1/session.json?login=u&password=pwd&method=put


HTTP/1.1 200 OK
Date: Tue, 30 Jul 2013 09:12:01 GMT
Server: Apache
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Last-Modified: Tue, 30 Jul 2013 09:12:01 GMT
Set-Cookie: PHPSESSID=63f95d9d1676bd9987df65a6ba862d13; path=/
Content-Length: 146
Content-Type: application/json


{
"meta": {
   "success":true,
   "status_code":200,
   "link":[],
   "rate_limit": 120,
   "rate_remaining": 120
},
"error":[],
"data":{
   "is_logged":true,
   "user_id":1,
   "firstname":"John",
   "lastname":"Doe",
   "gender":"H"
}
}
Dans un navigateur, le cookie de session est automatiquement envoyé à chaque requête et récupérer dans chaque réponse. Sans navigateur, il est nécessaire de récupérer le contenu de l’entête Set-Cookie des réponses de l’API pour le renvoyer dans les prochaines requêtes.

Généralité

Les réponses contiennent un paramètre meta.link qui peut contenir un ensemble de liens contextuels à la ressource. Ces liens explicitent les URLs vers les ressources directement liées à la ressource courante.

Les développeurs sont vivement encouragés à suivre ces liens plutôt que de les reconstruire eux-mêmes. Cela facilite également la prise en compte d’évolutions futures de l’API.

Pagination

Les ressources retournant une liste d’éléments sont paginées par défaut avec 20 éléments par page. Le paramètre limit des requêtes permet de diminuer cette valeur ou de l’augmenter jusqu’à 40. Une valeur supérieure à 40 sera refusée.

Le paramètre page contrôle le numéro de page. Les pages sont numérotées à partir de 0 avec une valeur croissante. La première page a le numéro 0, la deuxième le 1, etc.

Paramètre Description Valeur
limit Nombre d’éléments par page entier de 1 à 40. 20 par défaut
page Numéro de la page entier à partir de 0. 0 par défaut
 
Les ressources paginées contiennent des liens de pagination évitant au développeur de construire lui même. Ces liens reprennent tous les paramètres indiqués par la requête initiale :

Paramètre Description Valeur
meta.link.first_page Lien vers la première page URL
meta.link.next_page Lien vers la page suivante Contient une URL sauf pour la dernière page où le paramètre est à "false"
meta.link.previous_page Lien vers la page précédente Contient une URL sauf pour la première page où le paramètre est à "false"
meta.link.last_page Lien vers la dernière page URL
meta.items_count Nombre d’éléments total Entier
meta.items_per_page Nombre d’éléments par page Entier
meta.current_page Page courante Entier
L’API supporte les mécanismes de cache HTTP. Les réponses sont accompagnées d’entêtes de cache que le développeur devrait respecter. Les entêtes ETag et Last-Modified peuvent être utilisées indifféremment dans les réponses.

Si une de ces entêtes est présente et que la ressource n’a pas été modifiée depuis le dernier appel, une réponse 304 Not Modified sera alors retournée en réponse. Les réponses 304 ne sont pas comptabilisées dans le quota d’utilisation de l’API, c’est un très bon moyen d’optimiser sa consommation.

ETag

Une réponse peut contenir une entête ETag qui indique un numéro de série. Pour tout rappel ultérieur d’une même ressource, il est fortement conseillé au développeur d’inclure dans sa requête une entête If-None-Match contenant le numéro de série de l’élément.

$ curl -i http://monsite.kiubi-web.com/api/v1/blog/posts.json


HTTP/1.1 200 OK
Cache-Control: private, max-age=60
ETag: "644b5b0155e6404a9cc4bd9d8b1ae730"
Status: 200 OK
Vary: Accept, Authorization, Cookie
$ curl -i http://monsite.kiubi-web.com/api/v1/blog/posts.json -H 'If-None-Match: "644b5b0155e6404a9cc4bd9d8b1ae730"'


HTTP/1.1 304 Not Modified
Cache-Control: private, max-age=60
ETag: "644b5b0155e6404a9cc4bd9d8b1ae730"
Last-Modified: Thu, 23 Jul 2013 11:25:05 GMT
Status: 304 Not Modified
Vary: Accept, Authorization, Cookie

Last-Modified

Une réponse peut contenir une entête Last-Modified qui indique une date. Pour tout rappel ultérieur d’une même ressource, il est fortement conseillé au développeur d’inclure dans sa requête une entête If-Modified-Since contenant cette date.

$ curl -i http://monsite.kiubi-web.com/api/v1/blog/posts.json


HTTP/1.1 200 OK
Cache-Control: private, max-age=60
Last-Modified: Thu, 23 Jul 2013 11:25:05 GMT
Status: 200 OK
Vary: Accept, Authorization, Cookie
$ curl -i http://monsite.kiubi-web.com/api/v1/blog/posts.json -H "If-Modified-Since: Thu, 23 Jul 2013 11:25:05 GMT "


HTTP/1.1 304 Not Modified
Cache-Control: private, max-age=60
Last-Modified: Thu, 23 Jul 2013 11:25:05 GMT
Status: 304 Not Modified
Vary: Accept, Authorization, Cookie
L’API peut utiliser les mécanismes de redirection HTTP (codes HTTP 301 et 302) lorsque cela est nécessaire. Le développeur devra toujours prévoir l’éventualité de recevoir une redirection en réponse à une de ses requêtes. Dans ce cas la réponse contient une entête Location qui indique l’URL à laquelle le développeur est invité à renvoyer sa requête. Un exemple de redirection :

HTTP/1.1 301 REDIRECT PERMANENT
Server: Apache
Date: Tue, 30 Jul 2013 08:25:32 GMT
Content-Type: application/json; charset=iso-8859-1
Connection: keep-alive
Status: 200 OK
ETag: "a00049ba79152d03380c34652f2cb612"
Location: "/api/v1/new/endpoint.json"
Content-Length: 5
Cache-Control: max-age=0, private, must-revalidate


{
    meta : {
        success : true,
        status_code : 301,
        link : { location : "/api/v1/new/endpoint.json" },
   "rate_limit": 120,
   "rate_remaining": 120
    },
    data : {}
}

Le paramètre meta.link.location reprend la valeur de l’entête Location. Si le paramètre suppress_response_code est à true dans la requête, le code HTTP est un code 200. A la charge du développeur de tester le statut présent dans meta.link.status_code et de refaire un appel à l’URL indiquée dans meta.link.location.

Redirection 301 : c’est une redirection permanente. Toutes les requêtes vers la ressource désignée devront s’effectuer sur la nouvelle URL.

Redirection 302 : l’utilisation d’une nouvelle URL est temporairement nécessaire. L’URL d’origine est cependant toujours à utiliser pour adresser la ressource.

Les réponses 301 & 302 ne sont pas comptabilisées dans le quota d’utilisation de l’API.
Le quota d’utilisation de l’API PFO a été fixé pour en permettre une utilisation confortable. Chaque utilisateur a droit à 120 requêtes sur une durée de 2 minutes. A chaque requête, le nombre de requêtes restantes est décrémenté de 1. Au bout de 2 minutes, le quota est restauré à 120.

La quantité de requêtes restantes est indiquée dans chaque réponse dans le noeud meta.rate_remaining. Le point d’entrée /rate permet également de récupérer cette valeur sans consommer de quota.

$ curl -i http://monsite.kiubi-web.com/api/v1/rate.json


HTTP/1.1 200 OK
Date: Tue, 30 Jul 2013 09:12:01 GMT
Content-Length: 114
Content-Type: application/json


{
"meta": {
   "success":true,
   "status_code":200,
   "link":[],
   "rate_limit": 120,
   "rate_remaining": 120
},
"error":[],
"data":null
}

En cas de dépassement de quota, l’API renverra une erreur 403 :

$ curl http://monsite.kiubi-web.com/api/v1/blog/posts.json


{
  "meta": {
    "success": false,
    "status_code": 403,
    "rate_limit": 120,
    "rate_remaining": 0,
    "link": []
  },
  "error": {
    "code": 4300,
    "message": "Vous avez épuisé votre quota de requête, attendez quelques minutes pour restaurer votre quota.",
    "help": "",
    "fields": []
  },
  "data": null
}
Les requêtes qui ne consomment pas de quota sont celles vers le point d’entrée /rate ou celle générant une réponse 301, 302 ou 304 (cf. : sections "Cache" et "Redirections"). L’utilisation du cache est le meilleur moyen de limiter sa consommation.

Si ces quotas sont insuffisants pour votre site, n'hésitez pas à nous contacter !
Vous trouverez sur GitHub les sources et la documentation de plusieurs exemples concrets d'utilisation de l'API de Kiubi.

Produits géolocalisés

Tutoriel d'intégration de produits géolocalisés sur son site Kiubi.

Voir le tutoriel

Suggestion de produits

Tutoriel d'intégration de suggestion de produits avec l'API sur son site Kiubi.

Voir le tutoriel

Bundles de produits

Tutoriel de création des bundles de produits sur son site Kiubi.

Voir le tutoriel

Variantes multi-critères

Tutoriel d'intégration de variantes multi-critères de produit avec l'API sur son site Kiubi.

Voir le tutoriel

Listing dynamique

Tutoriel d'intégration de listing produits dynamique avec l'API sur son site Kiubi.

Voir le tutoriel

Contrôle de la médiathèque

Tutoriel d'utilisation de la médiathèque avec l'API de son site Kiubi.

Voir le tutoriel

Shortcode

Tutoriel d'intégration de shortcodes sur son site Kiubi.

Voir le tutoriel

Gestion de devis

Tutoriel d'intégration de formulaires avec l'API sur son site Kiubi.

Voir le tutoriel

Testez Kiubi gratuitement 30 jours pour créer votre site Internet ou votre boutique en ligne

Vous avez une question ? Besoin d'un conseil ou d'un devis ? Contactez-nous !