JeuWeb - Crée ton jeu par navigateur

Version complète : [Recherche][Développeur PHP/XML] API de l'annuaire JeuWeb
Vous consultez actuellement la version basse qualité d'un document. Voir la version complète avec le bon formatage.
Pages : 1 2
Bonjour,

Je suis en train de bosser sur l'annuaire JeuWeb et je souhaite fournir aux webmasters de sites traitant des jeux par navigateur un moyen d'accès (en lecture comme en écriture) aux données de cet annuaire.

Le but est donc d'écrire une API en PHP qui interrogera un service Web REST (l'annuaire) qui enverra des données formatées en XML. Pour effectuer ces requêtes, l'API utilisera la librairie cURL.

Le décor technique est planté. Je décris un peu plus la façon dont doivent se passer les échanges.

    Code PHP
$url = "http://sephichan.homelinux.net:3000/games.xml";
 
$handle = curl_init();
curl_setopt($handle, CURLOPT_URL, $url);
curl_setopt($handle, CURLOPT_RETURNTRANSFER, 1);
$xml = curl_exec($handle);


La variable XML contient :

    Code XML
<games>
  <game>
    <title>Seelies</title>
    <link>/games/1-seelies</link>
    <introduction>Seelies est un jeu de rôle communautaire dans 
    lequel vous évoluerez à l'échelle des insectes que vous devrez 
    soumettre pour  vous aider à étendre l'influence de votre 
    colonie.</introduction>
  </game>
  <game>
    <title>Exotech MS</title>
    <link>/games/2-exotech-ms</link>
    <introduction>Prenez le contrôle d'une armure mobile et défiez 
    vos adversaire dans toutes les arènes naturelles du mondes : des jungles 
    de l'Amazonie aux déserts arides de l'Afrique, saurez-vous concevoir une 
    machine assez polyvalente pour vous imposer ?</introduction>
  </game>
</games>


Le but est de créer une API agréable à utiliser qui va nous renvoyer de jolis tableau d'objets JW_Game, avec leurs petits attributs title, introduction, etc. et un petit attribut comments, qui contient lui même un tableau d'objets JW_Comment, toussa.

Et c'est là que j'ai besoin d'aide. 2 Écrire ce parser XML en PHP me prendrait du temps que je préfère investir dans le développement de l'annuaire en lui-même.

Si la personne intéressée souhaite poursuivre l'aventure, l'API devra également envoyer des données vers l'annuaire. Ainsi, les visiteurs du site qui affichera les jeux de l'annuaire JeuWeb pourront inscrire des commentaires sur ces jeux.

Je pense donc qu'il s'agit là d'une mission intéressante car différent de ce qu'on voit généralement, d'autant plus qu'il concerne directement JeuWeb. J'espère donc trouver des intéressés. 2

Vous pouvez me contacter par MP, ou bien via ce sujet, ou encore par MSN et par E-mail (ces informations se trouvent dans mon profil).


Sephi-Chan
Up.
oh l'autre, comment il up direct !
J'ai quelques petites questions concernant ce sérialiser XML :

- Peut-on utiliser des API telle que SimpleXML pour produire cet outil ?
- Est ce qu'il y a une architecture précise , une spec technique, un cahier des charges x) ?
- Tout est concentré sur un seul fichier XML (les commentaires pourraient être ailleurs par exemple ) ?
- Des fonctionnalités cachées pour une V2 (modération des commentaires ou autre ) ?
- Un délai de livraison ?
- Des tests unitaires ? 1

Bon je vais m'arrêter là. 10
La personne qui acceptera de réalise cette API pourra utiliser les outils fournis en standards par PHP5 pour XML (DOM, SimpleXML, XMLReader, etc.).

Je n'impose pas d'architecture particulière, il faut juste que ce soit simple à utiliser pour les webmasters qui l'utiliseront. Pour cela, l'API devra être documentée (au moins techniquement, idéalement avec un PHPDoc ou autre).

Pas de délais particuliers non plus, la personne n'a qu'à montrer l'avancement de son travail (ça me permettra éventuellement de lui donner un coup de main).

Une classe de test unitaire serait un plus, mais ça n'est vraiment pas indispensable. Je préfère que la personne favorise l'API en elle-même. 2

Concernant les fonctionnalités suivantes, il pourrait effectivement s'agir de modération à distance : mon application gère déjà les authentifications par HTTP, donc ça ne serait pas bien difficile à implémenter. 2


Sephi-Chan
si j'avais eu du temps, j'aurais été intéressé.
Néanmoins si c'est toujours d'actualité, j'ai un peu de temps libre en aout. (seulement en aout mais j'ai pas l'impression que cela prennent 10ans à faire)
>> Je n'impose pas d'architecture particulière...

indirectement peut-être si.
si ton webservice ne limite pas la taille des réponses (ou ne permet pas d'en faire la demande), alors simpleXML risque d'être hors course à un moment (bon faudra déjà que tu ais pas mal de succès avant que par exemple games.xml qui donnerait la liste complète des jeux avec description, etc... fasse plusieurs Mo).

en gros faudrait poser un peu les spéc technique du webservice 34
Il y a un système de pagination du côté de mon application : jamais une requête n'ira chercher tous les enregistrements d'un coup. 2

De plus, l'avantage des ressources servies est qu'elles n'ont pas une affichage conditionné : elles se prêtent donc très bien au cache "pur" (chaque page de réponse est stocké en cache et rafraîchie quand un jeu est modifié ou un commentaire posté).


Sephi-Chan
Up. Je cherche toujours une personne intéressée et capable de crée un interpréteur qui change un flux XML en un tableau d'objets.


Sephi-Chan
Comme Arius, je ne pourrai pas m'investir complètement parce que je n'ai pas de vacances tout simplement (ce qui équivaut en gros à quelques soirées et une partie du week-end).

Cela dit, l'idée m'intéresse et cela me semble pas trop compliqué à faire. Enfin tout cela dépend encore de la demande parce que dans ce parser je vois essentiellement deux alternatives :

- Soit tu veux juste un simple Wrapper XML<->Objet et c'est assez simple à concevoir. L'inconvénient étant que si demain tu veux la même chose en Json par exemple, il faudra revoir une partie de l'archi.

- Soit tu veux un vrai parser qui à chaque fois transforme ton xml en objet et inversement, ce qui donne plus de possibilités de sérialisation (comme cité en haut : le passage en Json sera moins pénible). Par contre l'API est plus lourde et plus complexe à concevoir (donc un temps de dev plus important).

On peut imaginer un mélange des deux, mais ce sera quand même plus long à développer que dans le cadre de la première solution. 1

Voilà si je pouvais avoir plus de détails , ça me permettrait d'estimer le temps de dev, et éventuellement me convaincre de le faire. 2
Pages : 1 2
URLs de référence