[AlternC-dev] Cas pratique de besoin utilisateur N°1

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

Remi remi+tech at b6.be
Mar 27 Mai 09:52:14 CEST 2014


On Tue, 27 May 2014, cam.lafit at azerttyu.net wrote:

|Bonjour
|
|L'authentification n'est pas un problème. Elle n’empêche pas de faire
|fonctionner l'api. Ce sont 2 points différents, qu'on peut traiter
|dans l'ordre qu'on veut.
|Du fait des évolutions sur les options, acl, ... Il est probable que
|du oauth ou assimilé sera à mettre en place. On doit pouvoir gérer
|tant en admin tant en utilisateur, tant en cli locale. Toutes ces
|possibilités ne changent pas le fonctionnement de l'api.

On peut dissocier deux types d'API pouvant coexister:

* la première : un RPC purement interne dans une topologie "serveur(s) 
AlternC" / "backoffice AlternC PHP".

On imagine donc un "/domains/2014/list/xml" pour avoir la liste des 
domaines de l'uid 2014 en XML.

Celle-ci n'aurait (au conditionnel) effectivement pas besoin 
d'identification (tout en protégeant son utilisation).

Cette "API" serait donc utilisée par le frontoffice AlternC pour 
communiquer avec le backoffice. On peut donc effectivement dire que 
l'identification de l'utilisateur final est secondaire dans cette 
topologie.

* la seconde : une API orientée client final

Dans le cas d'une API publique (ce qui est une chose différente), 
l'utilisateur doit s'authentifier pour avoir accès à des droits 
restreints (/domains/list/xml renverra mes domaines uniquement)

C'est également le genre d'API qui serait utilisée par des backoffice 
HTML5/JS, entre autres exemples, ou par les utilisateurs finaux dans leurs 
scripts.

----

Concernant oAuth, j'ai du mal à comprendre au niveau des ACL en quoi il 
pourrait faciliter les choses, mais j'avoue ma méconnaissance du sujet.

|Parmi les poins à prendre en compte; il y a le suivi de version de
|l'api, pour ceci je préconise celle exploitée par github via les
|HEADER : https://developer.github.com/v3/#current-version . Je vois
|cette approche arriver de plus en plus sur les api récentes

Cette approche serait bonne si les utilisateurs devaient obligatoirement 
mentionner le numéro de version, et non de manière facultative. Peu le 
feront, il suffit de voir l'exemple juste en dessous, où la commande 
"curl" est passée sans le header "Accept". Bref, le jour où ils changent 
de version, des milliers d'utilisateurs seront ennuyés. On pourrait le 
rendre obligatoire, mais ajouter un header oterait de la facilité au 
processus.

La bonne méthode est plutôt celle mentionnée pour les entreprises par 
Github ("yourdomain.com/api/v3/") où le numéro de version fait partie 
intégrante de l'URL appelée... enfin c'est mon avis. Mais ça garantit une 
véritable continuité de service malgré les évolutions, et les ruptures 
de compatibilité ascendante.

Remi


Plus d'informations sur la liste de diffusion Dev