[AlternC-dev] API Rest

Retour à l'archive de la liste
Le site d'AlternC
Google Custom Search

Remi remi+tech at b6.be
Mer 7 Mar 12:07:56 CET 2012


Salut,

Je percevrais bien des appels interchangeables soit en POST, soit en GET 
de ce style:

* Méthode 1 en POST:
POST /rest/nom_service/nom_fonction/format_sortie HTTP/1.1
arg1=blabla&arg2=blabla&arg3=blabla

(possibilité d'utiliser tout type de requête POST style multipart, puisque 
de toute façon c'est géré par PHP).

* Méthode 2 en GET:
GET /rest/nom_service/nom_fonction/format_sortie?arg1=blabla&arg2=blabla&arg3=blabla HTTP/1.1

Les classes services doivent être des ressouces d'abstraction (pas les 
classes AlternC actuelles); des classes intermédiaires qui encapsulent les 
appels afin de garantir une évolution transparente du corps applicatif 
actuel.

Il faudrait voir si l'authentification devrait se faire plutôt par cookie 
(clé API permanente), soit par un préappel à une méthode donnée pour 
s'identifier et initier une session
POST /rest/auth 
login=truc&pass=machin

ou header Cookie: API_KEY=7d18d98d1b2285a2258d656e2f27ce26

Ce que fait Google pour ses API me semble bien pensé: 
http://code.google.com/intl/fr-FR/apis/maps/documentation/geocoding/, sauf 
qu'ils ne prévoient pas (sauf erreur de ma part) l'envoi en POST qui est 
un élément sécurisant. En tous cas, le fait de pouvoir choisir entre une 
sortie XML ou JSON, est une chose importante pour les futurs besoins 
applicatifs (le JSON étant bien adapté coté client riche, là ou le XML est 
un langage universel et facilement parsable).

En dehors du script "rest/" qui initialise la session d'un utilisateur, 
dispatche les requêtes et les paramètres à chaque fonction de classe et 
convertit le retour des fonctions en code json ou xml, il ne resterait 
qu'à coder des classes pour chaque service qui ressembleraient à quelque 
chose du genre:

Class Domain extends AbstractAPIClass {
	function add($params=Array()) (
		// vérifications des paramètres
		if (!isset($params['domain'])) throw new Exception("Paramètre domain absent");
		...
		// ajoute le domaine
		$ERROR=!$this->Alternc->dom->add($params['domain'], params['dns'], $params['erase'], $params['force']);
		if ($ERROR) return Array("code" => "ERR");
		return Array("code" => "OK");
	}
}

Le plus difficile n'est pas de coder tout cela je pense, c'est plutôt de 
dresser la liste des API dont nous avons besoin, et d'en faire quelque 
chose d'accessible, flexible et évolutif.

Pour ce qui est de l'utilisation d'un framework PHP, je n'en vois pas 
spécialement l'intérêt, vu que je ne pense pas que ça prenne 100 lignes de 
faire le script "rest/", le principal à développer pour nous étant les 
classes d'abstractions liées à nos API. Mais il est possible que je puisse 
être trop optimiste ;)

Remi

On Tue, 6 Mar 2012, cam.lafit at azerttyu.net wrote:

|Yop
|
|De façon informelle je pensais aussi à encapsuler les méthodes "core"
|dans une ressource REST. Les 2 frameworks identifiés le permettraient
|facilement.
|On peut me semble t il faire une correspondance objet instancié /
|ressource comme l'indique Alan.
|
|Le truc où je ne rejoins pas c'est qu'on doit raisonner en ressource,
|avec cet exemple je prend peur.
|> rest/login/nom_classe/nom_fonction/arg1/arg2/arg3
|
|ce qui n'est pas le cas pour nom_classe et nom_fonction, quoiqu'on
|peut en se triturant un peu mais bof :)
|ce qui n'est clairement pas le cas des argX ça, à mon sens ce sont des
|arguments à fournir à la ressource sollicitée et surout pas dans l'URI
|(faudrait gérer le sens, gérer les cas où un argument est
|facultatif,....) .
|
|Le truc aussi que je n'ai pas dit mais pensé très fortement c'est
|qu'une fois définie une structure des accès aux ressources on obtient
|de fait notre alternD. Vu qu'on peut alors isoler complétement
|l'interface graphique de ce qui est derrière.
|
|Si on pense http on peut solliciter un format de retour pour chaque
|ressource. Ainsi on peut avoir le format json, le html, le array php,
|... comme le disait Dominique.
|
|Je pense vraiment qu'il faut formaliser une logique d'accès aux
|ressources sans se demander comment on codera ceci. Faire une approche
|bourrin rendrait instable l'api associé ce qui irait à l'encontre
|complète la notion même d'api ...
|
|Voili voulou.
|
|PS De mon coté le besoin initial c'est de dire depuis mon dolibarr :
|créé le compte "toto" avec un ftp et le domaine "titi.tld"
|_______________________________________________
|Dev mailing list
|Dev at alternc.org
|http://lists.alternc.org/listinfo/dev
|



Plus d'informations sur la liste de diffusion Dev