[API] Arborescence des fichiers

[leosw]

Salut à tous

Pour l'API, je reste dans mon idée de têtu qui consiste à mettre tout dans un sous dossier, pour bien montrer qu'il ne doit y avoir aucun lien entre l'API et le reste.

Voilà donc l'arborescence des fichiers à laquelle je pense. (alors je ne suis pas sûr de moi)



Pour info, le mail.txt est pour stocker les mails, de manière à informer les utilisateurs lors d'un changement de l'API.

Léo

[sly]

Pour l'API, je reste dans mon idée de têtu qui consiste à mettre tout dans un sous dossier

Moi pas comprendre.
On s'est battu pour passer à MVC, ta proposition respecte ce modèle, et on a une organisation du site (sauf OL et forum et /gestion) et tu voudrais rajouter une nouvelle spécificité pour que l'api soit en dehors du format de rangement du reste ?

pour bien montrer qu'il ne doit y avoir aucun lien entre l'API et le reste.

Hein ?
C'est de toute façon utopique de croire que ça va être "sans aucun lien" ou alors tu vises de te retaper tout le code du site qui se trouve dans /modeles pour que ne soit en commun que la base de donnée.
Ou alors j'ai pas tout compris...

Voilà donc l'arborescence des fichiers à laquelle je pense. (alors je ne suis pas sûr de moi)

ça me semble avoir une bonne tête, je ne commencerais juste pas mes fichiers par "api_" vu que c'est déjà dans le dossier de l'api

Je comprends un peu la volonté "rangement séparé", mais on doit pouvoir trouver un intermédiaire, exemple d'idée :

/controlleurs/api/
--> point.php
--> polygone.php
--> recherche.php
--> (etc)

/vues/api/
--> point.pdf / point.json / point.gml / point.csv
--> polygone.gml
--> recherche.gml / recherche.gpx (pas convainu moi même)
--> (etc)

Ton modeles se situe dans /modeles
includes ? pdf.php ça serait une classe génératrice de pdf ? alors je propose
/vendors
(j'ai l'impression que c'est devenu un classique pour mettre des classes en provenance de tiers que l'on ne compte pas toucher)

[leosw]

Je comprends un peu la volonté "rangement séparé", mais on doit pouvoir trouver un intermédiaire, exemple d'idée :

Je suis d'accord avec ton idée, ça me va.

C'est de toute façon utopique de croire que ça va être "sans aucun lien" ou alors tu vises de te retaper tout le code du site qui se trouve dans /modeles pour que ne soit en commun que la base de donnée.

Je comptais sur l'API pour venir remplacer le code existant, donc ce serait une copie, mais si tu penses que c'est trop compliqué, on peut effectivement utiliser les fonctions existantes.

[leosw]

Pour mon envie de rendre l'API complètement indépendante c'est que la base de donnée n'est pas sujette a évolutions fréquentes, ou plutôt que l'évolution de l'API n'as pas de liens avec le côté graphique.

Alors que le côté graphique évolue, on observe clairement une évolution sur la norme HTML, les technologies de présentation, des avancées dans les librairies Javacript...

En fait, dans ma tête, je pense que la solution c'est une base de donnée accessible via un API (pouvant même se trouver sur un nom de domaine externe), et d'un autre côté l'interface client.

Soit en conclusion avoir une distinction backend/frontend, ce qui n'est pas le cas ici, on a un peu tout de mélangé...

Remarque, pour /vendors, soit on met tout en anglais, soit tout en français non ? Là on jongle un peu entre les deux...

[Dominique]

Bonjour

Pour faire simple, je regrouperais en MVC au même niveau l'affichage du site (point.html ), les sorties"API" (point.json) et les exportations (export_gml.php)
Donc :
/modeles/*.php
/vues/*.php
/controlleurs/*.php
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)

Note: conçu comme ça, il est possible d'avoir une API lecture/écriture sécurisée en ayant le même contrôleur point pour le html et le json, ledit contrôleur gérant la sécurité pour les retours POST du HTML saurait les gérer pour le json

[leosw]

J'ai peur, qu'à force de vouloir intégrer l'API autant que possible dans l'existant, si dans le futur on veuille re-coder l'interface ou réécrire la base de donnée, nous ne devions tout refaire.

[Dominique]

J'ai peur, qu'à force de vouloir intégrer l'API autant que possible dans l'existant, si dans le futur on veuille re-coder l'interface ou réécrire la base de donnée, nous ne devions tout refaire.

Ben, au contraire, plus on factorisera, moins on aura à recoder
Evidement il faut bien standardiser l'interface et ce que j'ai vu de vos spécs précédente me semble aller dans le bon sens

[leosw]

Le soucis, c'est que à force de factoriser, on a de nombreuses exceptions qui arrivent, suffit de regarder ici :

https://github.com/sletuffe/www.refuges ... &type=Code

[sly]

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

[leosw]

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.

Pour moi tu as listé toutes les bidouilles que j'ai du faire, et donc je pense effectivement comme toi pour l'API, ce qui sort est brut (même si dans mon schéma on voit une option pour formater en html ou markdown au choix).

Personellement je suis pour le retour unique pour un point, si le besoin se ressent on pourra diviser le fichier en plusieurs, mais je pense que c'est plus compliqué.