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

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

Alban Crommer alban at octopuce.fr
Mar 27 Mai 10:35:30 CEST 2014


Ola


Concernant l'API

1. la page wiki OK est bien http://alternc.org/wiki/Documentation/Fr/Administrateur/Api ?

2. le squelette de classe actuel est http://alternc.org/browser/alternc-restapi/trunk/bureau/class/m_api.php?rev=4572 ?

Concernant cette réunion de dev, personne n'a de dispo dans le mois de juin ? J'aime pas faire mon relou, mais on constate quand même que le développement d'Alternc se fait par poussées et que sans ces réunions, on avance pas des masses. Mais je veux bien que ça change et qu'on me démontre le contraire :)

@fser et toi tu penserais à quoi comme auth ?

a


----- Original Message -----
> From: "Remi" <remi+tech at b6.be>
> To: "Liste de Développement de nouvelles fonctionnalités pour AlternC" <dev at alternc.org>
> Sent: Tuesday, May 27, 2014 9:52:14 AM
> Subject: Re: [AlternC-dev]	Cas pratique de besoin utilisateur N°1
> 
> 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
> _______________________________________________
> Dev mailing list
> Dev at alternc.org
> http://lists.alternc.org/listinfo/dev
> 


Plus d'informations sur la liste de diffusion Dev