Je me demandais si il était prévu de développer une API qui permettrait de récupérer aisément diverses informations à propos des personnages sur le serveur.
Ou éventuellement si vous seriez favorable à ce que quelqu'un le développe.
Fournir ainsi des outils permettant par exemple de récupérer les informations de son personnage pour les mettre dans une signature de forum ou sur un site de guilde.
Il suffit d'un accès SELECT à une ou deux tables ('dolcharacteres' m'a-t-on dit) pour développer des scripts php permettant de récupérer ces informations.
Si ce n'est pas clair, mettons que je veuille mettre sur mon site la liste de tous les membres de ma guilde "Les Bourrins" je n'aurai qu'à insérer à ma page "http://www.lesbourrins.com/membres.php" un code qui pourrait ressembler à ceci :
Il est prévu ce genre de choses pour les membres de l'association.
Mais comme pour l'affichage du nombre de joueurs, ou pour le rvr (actuellement désactivé) nous n'effectuons jamais les requetes directement sur le serveur.
A des fins d'optimisation d'une part.
Et de sécurité d'autre part.
Le système est donc un peu plus compliqué, utilise des tables temporaires sur un autre serveur sql, et n'effectue les requetes qu'une fois toutes les 5 minutes.
Bref, c'est assez long a mettre en place, et pas vraiment très utile pour le moment.
Dans l'absolu je suis plutot pour, ca peut donner lieu à des choses tres interessantes, si tu trouve un moyen solide d'eviter le surcharge de requetes (par quelqu'un qui raffraichirait la page 20 fois par seconde);
Eventuellement créer des vues sur une autre base via des triggers ... dunno;
Plaintes: (En cas de plainte sur le forum, vous vous exposez vous même au ban.) Administrateurs: Sp4M[at]Amtenael.com - Malkavien[at]Amtenael.com - Darkpepper - Dre GMA: ? GMT: ?
Effectivement le problèmes de surcharge et de sécurité sont à prendre en considération mais à mon humble avis il faut relativiser.
Cela étant dit, concernant les problèmes évoqués, quelques solutions me viennent à l'esprit :
Niveau sécurité :
Créer un utilisateur spécifique ("apiuser") qui n'aurait accès qu'à la requête SELECT uniquement sur la table contenant les informations souhaitées.
=> On parvient ainsi à prévenir les accès non autorisés.
Si le système le permet, créer une vue sur les éléments que l'on souhaite utiliser avec l'API.
=> On parvient ainsi à préserver l'intégrité des données.
Créer une base de données, appelée par exemple "api", ne contenant qu'une seule table, celle-ci étant une copie de la table contenant les informations dans la base dol de production.
La base "api" peut même être stockée sur une machine à part et carrément un réseau à part si on veut être secure à 110%.
La mise à jour de la base "api" peut se faire facilement notamment via un cronjob exécutant toutes les cinq minutes un script shell ou PHP qui copie les données.
=> On parvient ainsi à cloisonner les informations.
Niveau ressources :
Les requêtes (surtout les SELECT) sont souvent mises en cache pour un accès plus rapide. Certes il y a toujours des accès à la base mais moins de traitement.
J'ai déjà eu l'occasion de développer une API dans ce style pour un réseau IRC. Elle permet de récupérer des informations exhaustives concernant un channel donné telles que le sujet du topic, le nombre d'op, la liste des voice, etc...
Et par expérience, on ne peut pas vraiment dire que l'API soit surchargée.
Les gens ne s'amusent pas a refresh une page Web pendant des heures pour le plaisir.
Indexer les champs de la table de l'API pour éviter au système les parcours séquentiels et lui permettre d'accéder directement aux données.
Les temps d'accès seront donc drastiquement améliorés au détriment de l'espace disque nécessaire pour stocker les index.
Stocker les informations dans de simples fichiers texte mis à jour avec un cronjob. L'API se contenterait de parser les fichiers texte.
Il va sans dire que certaines de ces solutions peuvent être combinées pour accentuer l'optimisation.
J'admets que certaines de ces solutions mettent un certain temps à être mises en place mais d'autres se font relativement rapidement.
Pour les informations telle que l'appartenance à une guilde ou bien les détails d'un personnage, une table temporaire qui se met à jour ne serait ce qu'une fois par 24h serait je pense bien suffisant, on a pas besoin de voir ça en temps réel à ce point ^^
BilbU, si tu commences la chose et que t'a besoin d'un coup de main, hésites pas à me contacter au boulot je suis justement en pleins dans les requetes sql (et aussi les thread mais c'est autre chose -_- )
Asenar Lunin, furtif..., Encyclopédie
Furtif, mais moins..
BilbU wrote:Effectivement le problèmes de surcharge et de sécurité sont à prendre en considération mais à mon humble avis il faut relativiser.
Cela étant dit, concernant les problèmes évoqués, quelques solutions me viennent à l'esprit :
Niveau sécurité :
Créer un utilisateur spécifique ("apiuser") qui n'aurait accès qu'à la requête SELECT uniquement sur la table contenant les informations souhaitées.
=> On parvient ainsi à prévenir les accès non autorisés. => A noter que meme sur dolcharacters vous n'aurez jamais la totalité des champs
Si le système le permet, créer une vue sur les éléments que l'on souhaite utiliser avec l'API.
=> On parvient ainsi à préserver l'intégrité des données. => Un SELECT preserve aussi les données, btw
Créer une base de données, appelée par exemple "api", ne contenant qu'une seule table, celle-ci étant une copie de la table contenant les informations dans la base dol de production. => J'imagine qu'une vue devrait faire l'affaire, sinon oui, il faudrait un cron .. tu sais mettre ca en place ? :°)
La base "api" peut même être stockée sur une machine à part et carrément un réseau à part si on veut être secure à 110%. => On ne peut pas faire de cross requesting (!)
La mise à jour de la base "api" peut se faire facilement notamment via un cronjob exécutant toutes les cinq minutes un script shell ou PHP qui copie les données. => Si il est question de dolcharacters, une telle mise a jour ne se fera certainement pas toutes les 5 minutes (+ de 50000 enregistrements), mais eventuellement une fois par jour.
=> On parvient ainsi à cloisonner les informations.
Niveau ressources :
Les requêtes (surtout les SELECT) sont souvent mises en cache pour un accès plus rapide. Certes il y a toujours des accès à la base mais moins de traitement. => A voir .. Question, une requete sur une vue prend-elle finalement moins de temps que sur une table de plus grand nombre d'arguments ?
J'ai déjà eu l'occasion de développer une API dans ce style pour un réseau IRC. Elle permet de récupérer des informations exhaustives concernant un channel donné telles que le sujet du topic, le nombre d'op, la liste des voice, etc...
Et par expérience, on ne peut pas vraiment dire que l'API soit surchargée.
Les gens ne s'amusent pas a refresh une page Web pendant des heures pour le plaisir. => Detrompe toi, les gens sont capable de tout quand il s'agit de faire chier
Indexer les champs de la table de l'API pour éviter au système les parcours séquentiels et lui permettre d'accéder directement aux données.
Les temps d'accès seront donc drastiquement améliorés au détriment de l'espace disque nécessaire pour stocker les index.
Stocker les informations dans de simples fichiers texte mis à jour avec un cronjob. L'API se contenterait de parser les fichiers texte.
=> Le terme "fichier texte" pour une table de 50.000+ me fait tresaillir :°)
Il va sans dire que certaines de ces solutions peuvent être combinées pour accentuer l'optimisation.
J'admets que certaines de ces solutions mettent un certain temps à être mises en place mais d'autres se font relativement rapidement.
Plaintes: (En cas de plainte sur le forum, vous vous exposez vous même au ban.) Administrateurs: Sp4M[at]Amtenael.com - Malkavien[at]Amtenael.com - Darkpepper - Dre GMA: ? GMT: ?
Plaintes: (En cas de plainte sur le forum, vous vous exposez vous même au ban.)
(et aussi les thread mais c'est autre chose -_- )