Dominique a écrit :
Je ne vois pas de raison d'appeler les sorties json "api". C'est un format comme un autre (bien que pas très convivial sur un explorateur, j'en conviens)
Peut-être qu'on ne parle finalement pas de la même chose. Pour moi, cette API a pour but 1er d'exporter les données de wri brutes=telle que dans la base, pour que cela puisse être exploité dans des applications clientes que sont :
- OpenLayers (appel par bbox, par type de point)
- googleearth (points au format kml)
- gpx (pour des appareil GPS)
En gros, l'équivalent de l'exportation d'aujourd'hui. Avec en réflexion, la possibilité d'exporter les commentaires avec le lien vers les photos pour une appli cliente plus complexe, mais dont le code d'interaction n'est pas coté site mais coté client.
L'usage aujourd'hui de la vue "point.json" qui fourni un json avec une interprétation du bbcode, la liste des points à proximité, la transformation des emails en code "caché", la mise en forme d'url, un array de commentaires n'est, selon moi, pas quelque chose qui rentre dans le cadre de ce que doit faire cette API.
Mais plutôt, de même nature que le contrôleur point.php qui prépare les infos de la vue point.html en interrogeant le modèle et qui effectue des traitements en vu de la vue.
Ou alors, on considère que la version mobile du site est autonomes pour afficher comme elle l'entend, et alors elle appelle l'API à plusieurs reprise pour récupérer les données brutes :
- 1 appel pour les infos du point X
- 1 appel pour les commentaires qui se rattachent à X
- 1 appel pour les points dans un rayon de 5km de X
- 1 appel pour les points dans la bbox de la mini carte
- 1 appel par code [->Y] pour chaque lien qui va vers un autre point et dont on veut le nom
Et là, cette appli a son code de traitement "en local" et ne fait que des appels pour les données, la mise en forme est de son ressort