Je dirais même 3, 2 http GET effectivement et une troisième, que je suis pour le moment le seul à utiliser, qui est :Il y a actuellement 2 API sur refuges.info
Je confirmesly a écrit : -- ou pour des "sites partenaires" mais je ne sais pas si c'est toujours utilisé
Pb résolu: tous ces pb avec l'appli chrome qui [censuré] complètementsly a écrit :smartphone, j'ai android 2.3 avec firefox mobile :
OL n'est pas terrible en effet, certains contrôles ne répondent pas, mais ça reste jouable, et pour compléter, y'a www.refuges.info/mobile- les cartes sont catastrophiques : impossible de faire un zoom, de changer de fond de carte, de passer plein écran...
ici ça marche- La localisation ne marche pas, ce qui est un comble sur un mobile
ici ça marchemais pas la barre de menu qui se met en vrac. Et sans menu, on ne va pas loin.
ici ça marche.- Par contre, tout se gâte sur les pages de saisie : le CSS [censuré] complètement, la taille des champs varie ridiculemet et on passe son temps à zoomer.
Depuis que tu as dit ça je cherche mais je ne vois en effet pas d'avatage. J'ai du vouloir copier GML.Sly a écrit :API XML ? genre XML RPC ? ben pouquoi pas si on me prouve les avantages, mais ça me semble plutôt compliqué pour pas grand chose.
Code : Tout sélectionner
API GET -> dans une phase 1, je pense en en effet à de l'extraction de données, donc ni affichage (c'est quoi ça une "api d'affichage" ?), ni ajout/modif mais pourquoi pas pour plus tard. En mofification, en utilisant la même url action que le formulaire html: wri/point_ajout_commentaire/1245... qui va s'assurer que l'utilisateur est bien connecté...leosw a écrit :Par API affichage, je voulais dire lecture seule. Et ça permet de limiter l'injection de code (comment s'assurer que le partenaire est bien sécurisé contre les robots ?)
Pour contrer l'injection de code, il suffit d'utiliser des switch pour gérer les variables GET, je pense que ça suffit vu que c'est de la lecture seule.
Excellente remarque, en appel xml rpc, on aurait pas cette limite de longueur de l'url. Je pense qu'on a de la marge pour l'instant, mais à garder à l'esprit, surtout, je pense, si on fait évoluer vers une API de modification (une fiche complète ne tiendra certainement pas dans l'url) mais à ça moment là, il sera jamais trop tard d'ajouter un payload xmlDominique a écrit : Attention tout de même à la longueur de l'url
A ok ! Je n'avais pas compris ça. Ma remarque ci-avant concernant l'api d'affichage devient caduque.leosw a écrit : Par API affichage, je voulais dire lecture seule.
On ne peut pas s'en assurer, il faut donc tester avec soin que tous les paramètres qui seront passé par cette api seront bien conforme au format attendu.Et ça permet de limiter l'injection de code (comment s'assurer que le partenaire est bien sécurisé contre les robots ?)
Tant qu'on accepte pas de modif, le risque de XSS (http://fr.wikipedia.org/wiki/Cross-site_scripting ) reste faible, et en interne, il faut de toute façon que la fonction de récupération des données n'accepte pas n'importe quoi sous peine de faire planter la requête SQL donc autant mutualiser.Pour contrer l'injection de code, il suffit d'utiliser des switch pour gérer les variables GET, je pense que ça suffit vu que c'est de la lecture seule.
