[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 16:12:37 CEST 2014


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

|Ciao
|
|J'essaye de répondre au mieux mais il est certain que certaines de mes
|évidences ne le sont que pour moi, j'essaye de clarifier au mieux mais
|je peux rater des points :)

Salut,

Sur la forme des adresses à utiliser pour les API, il faut effectivement 
regarder ce qui se fait ailleurs.

J'aime beaucoup, sans rire, ce qu'a fait OVH:
https://api.ovh.com/console/
et il faudrait que nous arrivions à faire un travail similaire

Je pense que nous concentrer sur l'API externe est le plus stratégique à 
l'ordre du jour. 
L'échange RPC entre un frontend et différents backend n'est pas à l'ordre 
du jour.

Tu as raison, le format de sortie peut être stipulé en paramètre à la 
manière de ce qui se fait ailleurs "?format=json", "?format=xml". Mais 
pour moi le nom du service est celui qui correspond au module utilisé donc 
"/domain/", "/mail/", etc.

|De fait l'api demande déjà de définir des informations dans le header
|(POST/GET/PUT/...), Cela n'alourdit pas le processus de rajouter une
|entete de plus. Le processus n'est pas rendu plus compliqué.

[...]

|> 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.
|
|Là j'invite à relire les documentations liées. Mais c'est bien la
|version avec Accept qui est bien préconisée par Github que ce soit
|entreprise ou autre.

Voir ici
https://enterprise.github.com/help/articles/using-the-api

Et je faisais référence aux exemples listés dans leur doc, 
particulièrement dans le paragraphe qui suivait celui que tu avais envoyé:
https://developer.github.com/v3/#schema

Dans tous leurs exemples où ils utilisent "curl", jamais ils ne 
définissent pas le header Accept. Et puisque ceux qui utilisent leur API 
s'inspirent de leurs exemples, ça va faire un beau gachis s'il y a une 
rupture de compatibilité.

Mais rien en effet n'empêche de gérer le header Accept, pour ceux qui 
veulent bien l'utiliser.

Remi


Plus d'informations sur la liste de diffusion Dev