plateforme de jeu sur le web

Dans les jeux web classiques, qu'est ce qui fait leur succès ?

ogame

• on peut presque tout le temps faire qq chose.
• on peut jouer 2 minutes par jour comme 12h par jour.
• grouper les joueurs par alliance.
• auto-organisation des alliances.

Exolandia

• principe d'élection qui permet d'impliquer les joueurs dans la direction que prend le jeu.
• à chaque niveau des objectifs différents.

La ferme à dd

• il est possible d'inventer des recettes à partir d'aliments de base.
• application flash jolie... mais aussi un point négatif, car lente et pas d'onglet... donc très linéaire.
• grand nombre d'objet à échanger.

Grand principe

• partager
• accumuler
• prendre un rôle
• créer
• prendre du pouvoir
• avoir de la reconnaissance

(pyramide de maslow ?)

Architecture répartie

Un moteur de jeu n'est pas tout seul, n'importe qui doit pouvoir mettre en place un serveur de jeu et s'interconnecter avec d'autres qu'il connaît ! Les villages d'exolandia peuvent être autant de serveurs différents. Seule une API de communication est définie. Cette communication se fait via des services web. Des flux rss (pour le mail entre joueur par exemple.) La frontière entre le jeu et le dehors du jeu doit être la plus fine possible. Il ne sert à rien de re-développer tout et n'importe quoi ! Les utilisateurs veulent partager des images... et bien rendre le jeu compatible avec Flickr.

compter sur les joueurs pour faire le jeu

Le plus dur dans un jeu, surtout s'il prend de l'ampleur, c'est de suivre le développement, de réparer les bug et de répondre aux questions des joueurs.

Comme pour un forum, il faut mettre en place des modérateurs et des administrateurs qui font régner l'ordre ! (ou l'anarchie !) Il faut que le jeu s'auto-équilibre pour qu'il soit viable et intéressant.

Le mieux c'est de permettre aux joueurs de créer les règles du monde dans lequel ils veulent vivre. Donc le plus adapté, c'est un genre de Nomic. Mais pour maintenir la cohésion entre les différents serveurs de jeu / mondes, il faut définir quelques règles de base qui sont immuables. Avec une telle approche du jeu, celui-ci peut être radicalement différent d'un monde à l'autre, mais théoriquement un joueur d'un monde doit pouvoir interagir avec un autre monde.

Selon le principe du Nomic, à la base, un monde est régit par très peu de règles, Puis le tout se complexifie. Les règles peuvent aboutir à un monde démocratique ou alors l'opposé, un monde régit par une dictature. Ou alors, c'est un intermédiaire comme une république.

Le plus dur va être de techniquement créer un système qui permet de suivre les règles mise par les joueurs. Pour cela, le mieux c'est de créer un wiki pour indiquer les règles au format texte... et ensuite, les joueurs peuvent faire correspondre les règles avec des droits ou des restrictions dans le jeux.

implémentation

Il faut concevoir le système de façon souple. principalement jouer sur quelques concepts de base comme:

• les variables. Une variable est un moyen de mémoriser une valeur. Une valeur est soit juste une valeur simple, ou une valeur composée avec une requête.
• les groupes, permet de faire des structure de donnée complexe comme des listes, des tableaux ou des arbres.
• les règles, c'est une contrainte imposée à l'écriture ou la modification de donnée.
• les objectifs... donner une liste de variable et une liste des états souhaités. L'objectif est atteint lorsque toutes les variables sont des les états souhaités.
• les objets. Ce sont des groupes de type spéciaux qui sont des agrégats de variables.
• les éléments. Ce sont des éléments comme un article, ou une image qui ont leur propre fichier d'ajout / modification.
• les personnages / joueurs
• les niveaux / objectifs (une partie va être commune à tous les joueur et une autre seulement à certain monde.)

Chaque niveau correspond à des objectifs à atteindre.

Mettre à disposition des joueur certains outils. Par exemple:

• générateur aléatoire de choix.
• système de vote.
• horloge.
• système de création de groupe (associations)
• système d'attribution de tâche ou droit à des groupes. (un groupe peut être une personne seule.)
• place de marché, d'échange.
• un gestionnaire des outils disponibles.
• espace personnel bloc note.
• courrier avec d'autres utilisateurs
• lister les utilisateurs (d'ici et d'ailleurs)
• importer / ou copier (suivant leur nature) des objets provenant d'autre monde.
• un système de comparaison entre les joueurs. (les gens adorent faire des comparaisons entre eux. ça crée de l'information)

Chaque joueur doit être capable de proposer des nouveaux objets. Il ne peut peut être pas les posséder, mais d'autres les utiliser. (réfléchir au sujet de la propriété intellectuelle des objets)

Règles immuables et pré-requis d'interopérabilité.

• un joueur doit pouvoir vivre dans n'importe quel monde.
• il y a une unité de base qui est commune pour tous. (énergie, information, etc..)
• des objets doivent pouvoir être reconnu dans tous les mondes. (mais si dans certains monde, ils sont interdit de possession.)
• le temps est identique.
• chaque joueur est en droit de proposer des objets.

Unicité ?

Le monde industriel, énergétique, commerçant, est basé sur le principe de l'unicité. Tout est personnalisé dans cette société, tout est unique et pour cela on fiche les gens, on donne une identité, un numéro.

Faut il faire de même dans la conception de base d'une plateforme de jeu ? Est ce que chaque joueur doit être unique ?

Comment fait on avec les système de vote ? Qui ou quoi à le droit de vote ?

Le droit de vote dépend encore des règles en vigeur. Mais dans la mesure où l'on part du principe qu'un joueur est une entité unique. (on se fiche de savoir si c'est un multicompte ou pas.) Il faut rendre le vote unique. Pour ce faire il faut prendre le contexte du joueur, du vote concerné, et du calendrier. On passe tout ceci à la moulinette md5 et ainsi on obtient un moyen sûr de vérifier que le vote et unique.

Paradigmes principaux à implémenter

• Les variables
• Les groupes (avec héritage d'une propriété)
• Les états
• Les règles

C'est un peu les concepts minimaux dont il faut disposer pour faire un jeu de Nomic, donc les concepts principaux pour faire le moteur de n'importe quel jeu. (Hormis peut être la partie graphisme)

En fait ces principes sont également très semblables à ce que l'on trouve dans une base de données. Les données, les triggers, les contraintes d'intégrité !

Les variables

Les variables servent à mémoriser une information. C'est l'unité de base de stockage d'information. (bien qu'elle soit remplie d'unité d'information plus petites.)

Les groupes

Les groupent permettent de faire des associations entre des objets. Les groupes permettent de composer des objets complexes à partir de variables. Les groupent via la propriété d'héritage permettent de propager des informations à tout un groupe. Par exemple, voir le système de gestion des permissions de ce wiki.

Les états

Les états sont des états (!) précis de variables. Pour un jeu, un état peut être utilisé comme objectif, comme but. Un état est une généralisation d'un objectif, car un objectif est toujours une entité atomique, l'objectif est atteint ou non. L'état comporte des nuances. Un objectif a toujours une connotation positive, alors qu'un état peu aussi représenter une étape plus négative.

L'utilisation la plus courante va être de définir un état et de tester si l'état est vrai ou non. Donc si l'objectif est atteint ou non.

Les règles

Les règles sont des contraintes que l'on applique aux données. Les règles peuvent être des liens entre des variables et des états. Lors de chaque accès à une variable les règles sont vérifiées.

Il y a deux sortes de règles.

• les règles qui gèrent l'accès aux variables. Ex: A est accessible seulement si a+b > 3
• Les règles qui mettent à jour les variables après une modification. Ex: A = b + 2.. donc si je modifie b, va modifier A.

Ces deux sortent sont un peu des contraintes et des trigger ou écouteur.

Question pratique sur l'implémentation

Règles

Sous quelle forme stocker une règle ? Concrètement une règle c'est quoi ?

Dans un firewall, on rencontre des règles, pour ce genre d'activité c'est presque un langage verbeux qui est utilisé. Ci-dessus j'ai montré un exemple de règle avec un langage mathématique. Bref, que faire ? Pour éviter de se limiter, c'est presque d'un langage généraliste que l'on a besoin. Un langage dit de turing.

Une règle est, en fait, un bout de code. Dans un premier temps, la manière la plus simple que je vois de faire une règle est un bout de code php.

Puis, on remarque tout de même une certaine systématique dans les besoin. Cela reflète les opérateurs de base de tout langage de programmation. Il faut des accès en lecture écriture à des variables, il faut des opérateurs de comparaison. (=,>,<, !=), et des opérateurs de calcul (+-*/).

Si l'on prend en compte le définition de règles au sens large, une règle est souvent aussi la vérification d'un état. Une règle peut donc également être composée d'état.

En fait, l'état est peut être même plutôt un sous élément d'une règle, qui n'est pas forcément accessible à l'utilisateur final. C'est en fait l'état qui teste si des variables sont dans certains états prédéfini. La règle ne fait que de lier différents état. Pour lors de certaine action. Un règle est forcément liée à une action.

Comment traduire une règle du genre: Les règles du jeu sont définies par le conseil. ??

Dans cette règles, il faut identifier les acteurs et les actions. Nous avons le conseil comme acteur de l'action définir des règles. Cette phrase est en fait un peu trompeuse, car elle sous-entend que le conseil est formé de gens, mais sans le dire.

La règles va donc être une suite d'opération qui est attachée à l'action définir des règles. Dans cette suite on va tester si l'état utilisateur est dans le groupe conseil est vrai.

Donc pour s'exécuter, une action doit toujours vérifier que toutes les règles qui y sont attachées retournent vrai. C'est comme dans n'importe quel langage de programmation, il y a des procédures et il y a des fonction. La fonction retourne une valeur et la procédure exécuter une série de tâches, mais sans forcément retourner une valeur.

Dans notre cas, la règle va toujours retourner une valeur. Soit vrai soit faux. Pour qu'une action s'effectue, il faut que toutes les règles retournent vrai. Donc une règle procédure, va juste retourner vrai une fois qu'elle a finit son travail.

Il y a deux sortes de règles. Celles qui sont vérifiées avant l'action et celles qui sont vérifiées après. Une règle qui est vérifiée avant l'action. La plupart des règles sont vérifiées avant, car elle servent à la protection des données. Mais parfois, une règle définit ce qu'il faut faire suite à une action. Il est donc utile d'exécuter des règles après une action.

Quelques exemple, pour voir comment interpréter une règle.

• la règle: Les membres du conseil jouent chacun leur tour
• les acteurs sont les membres du conseil, il y a également une variable tour qui est un jeton unique. un joueur à la fois peut l'avoir.
• L'action liée est jouer. Jouer est une synonyme de proposer d'ajouter, supprimer ou modifier une règle.

Dans ce cas, la règle reformulée est du genre, pour propser d'ajouter, supprimer ou modifier une règle, l'utilisateur doit faire partie du groupe conseil et doit disposer d'un objet jeton unique dans le jeu.

• la règle: Chaque fois qu'un membre du conseil arrive à faire passer une nouvelle règle il reçoit 10 points pour sa patrouille.
• les acteurs sont: le membre du conseil qui propose une règle. Une variable point à augmenter de 10.
• l'action est ajout d'une nouvelle règle et la règle en elle même est a effectuer après l'action.

Dans la base de donnée, la table règle comporte:

• un id
• un nom
• un descriptif, qui est la version écrite de la règle.
• date_creation
• date_modification
• le type de la règle: à évaluer avant ou après l'action
• l'id de l'action à laquelle la règle est attachée.
• un numéro servant à peut être éventuellement faire un ordonnancement des règles.
• le nom de la fonction php qui correspond à la règles. (la fonction php est le moyen le plus simple pour réaliser l'implémentation d'une règle. Plus tard, je trouverai le moyen de réaliser ceci avec une interface graphique)

piste pour créer l'interface graphique....

une règle, est vrai si (condition 1) and (condition 2) and (condition 3) etc... ça c'est valable pour une règle qui tend à contrôler l'accès à des donnée. Pour une règle qui tend à mettre à jour des données après l'action c'est pas top...

Implémentation sans base de donnée.

Il est possible de faire une implémentation simplifiée sans base de donnée de ce système. Pour une jeu du nomic, il est clair que le but est de faire les règles, donc forcément il faut un système où il est possible de modifier les règles facilement et en toute sécurité pour le système.

Dans le cas où ce principe de règles est juste utilisée pour réaliser une gestion moins anarchique des accès à des actions, il est possible de placer les règles en dur dans la code.

Chaque action critique dans le code va être répertoriée. Avant de s'exécuter elle va demander à une classe gestionnaire si elle à le droit d'effectuer l'action ou non.

$gestionnaire = new gestionnaireAcces();
$gestionnaire->getDroit(); // effectue l'action si obtient true ou pas reçoit false

un état

Un état c'est quoi ? Plus haut on avait dit qu'un état est la valeur instantanée d'un certain nombre de variable. Puis il y a aussi ce que l'on appelait un objectif, qui est en d'autres termes une condition. si un objectif est remplis, la condition vaut vrai.

Au vue de la structure d'une règle, la notion de condition est fondamentale. On va donc créer un objet condition puis cet objet sera étendu à une liste de condition ce qui pour finir devient un objectif.

La notion d'état est basée sur le même raisonnement mais à partir de l'état d'une seule variable. (il faudra donc ré écrire le texte décrivant ce qu'est un état)

La notion de liste est faite, comme pour tout le reste avec la notion de groupe. Nous auront donc un groupe de conditions. Ce qui est même suffisant pour décrire une règle d'accès à des donnée. (il manque juste les infos spécifique à la règle.)

Donc, un condition c'est quoi ? Une condition est le résultat d'une comparaison entre deux variables. Il faut donc être capable d'obtenir la valeur d'une variable, puis il faut activer un opérateur de comparaison entre les deux. Les opérateur standard de comparaison sont ET, OU, =, !=, > et <. Ces dernier étant exclusivement utilisés pour des nombres.

Le stockage d'une condition se fait donc dans la table avec les champs suivant:

• id de la condition
• nom
• descriptif
• date_creation
• date_modification
• valeur1
• valeur2
• opérateur

Module de vote

Le module de vote est une composante indispensable pour faire une gestion démocratique des règles. Cependant, le vote peut être fait de multiple manière. De plus, il ne faut pas confondre vote et élection.

Le mode de vote le plus utile est le mode, un objet, une réponse: oui ou non.

Le principe est simple. Une action proposer au vote est définie. Celle-ci enregistre la proposition, avec des paramètres comme la date, et la personne qui propose. Puis une seconde action est définie: dépouiller le vote. Cette action clos le vote.

Après le vote, il existe donc une nouvelle variable quelque part qui contient le résultat du vote. Celle-ci peut être utilisée.

Le module en lui même est simple, il propose un minimum d'action. Ensuite ce sont les règles associées aux actions qui vont réglementer le tout. Par exemple associer une règle qui définit que la personne qui veut voter doit faire partie d'un groupe corps électoral et on peut compliquer l'accès pour faire partie de ce groupe.

Dans le cas d'une élection c'est un peu différent. Il faut une étape de plus qui consiste en l'inscription des candidats.

Module cron

Ce module permet de définir des tâches qui sont activées à une date et heure précise. Par exemple, si une règle dit qu'une période de votations dure 2 jours. Il faut faire une règle qui au moment où un objet est proposé enregistre une action qui va clore le scrutin 2 jours après.

Concrètement c'est l'utilisateur cron, qui va tenter d'activer l'action. Il faut faire attention au fait que cron doit avoir le droit d'activer l'action.

---

Les groupes standards

le groupe possessions

Pour déterminer si un objet est en possession de quelqu'un il faut qu'il y ait une liaison, entre l'objet et la personne. Pour imager un peu la chose on va créer un objet du genre sac qui contient toutes les possessions d'un utilisateur. (On peut aussi revoir le nom au lieu de sac, avoir, armoire, maison, inventaire, besace...). Ceci est utile pour être en possession d'un objet comme un jeton qui est l'implémentation de la règle ... à son tour....

Ceci pose la question de l'héritage des propriétés d'un objet. Peut être une liste de fonction, de propriété. Un objet sac n'est peut être qu'un objet disposant de la fonction conteneur. La règle du ...à son tour.. à seulement besoin de créer un lien entre les possessions d'un utilisateur et lui même. La règle à donc seulement besoin d'une fonction conteneur.

A voir comment faire pour qu'un objet puisse être dans différents objets, mais que le système puisse toujours les retrouver.

Quelques nouvelles idées

Voici, encore de manière très brouillon par ce que mes idées ne sont pas claires et sortent au fil que les écrit, quelques idées que j'ai eu pour créer des applications web.

Cette approche est en particulier intéressante pour des jeux comme j'ai tenté de décrire le fonctionnement ci-dessus. Cette approche permet aux utilisateurs de créer, sans trop de contraintes des objets, de les échanger et de les stocker sans que les concepteurs de la plateforme sache à l'avance à quoi ressembleront ses objets.

Google a lancé en automne 2007 sont projet OpenSocial qui est dans l'idée très proche. Il comporte une définition normalisée de ce qu'est une personne, propose un moyen de voir l'historique de l'activité de cette personne et surtout propose un service web de persistance basé sur AtomPub et REST.

Service web de stockage

Dans une application web on a toujours besoin de stocker des données. (variable, tableau, etc...). Pendant la durée de vie de l'application, la tendance et de tout faire en programmation objet, on a donc une multitude d'objets et de tableaux qui servent à stocker les données. Puis, pour le stockage à long terme, on utilise une base de donnée. Très fréquemment, on utilise le couple php/mysql.

Cependant, une base de donnée (mysql) n'est pas très pratique pour stocker des données vives. L'architecture des tables doit toujours être prévue à l'avance, ce qui contraint énormément l'application. Elle devient très rigide. Dès qu'il faut faire une modification, il faut ajouter un champ dans la base de donnée, puis modifier les fonctions qui permettent de faire de ajout, modification, suppression. Bref, c'est assez lourd.

Cependant, une base de donnée à aussi ces avantages, elle permet de faire très efficacement des tris de données un critère ou un autre.

Le but ici, est de concevoir un architecture de sauvegarde de données sur le web, avec des objets accessibles simplement de partout.

Type de données

On trouve différents type de données que l'on utilise fréquemment dans les application: int, string, date. Puis des structures de données: tableau, liste, pile, arbre, graphe.

Dans une base de donnée, on stocke des: varchar, text, datetime, int. Avec ces types, on crée des tables, une sorte d'objet.

Le but est de trouver un moyen de fédérer tous ces types de données pour trouver un format commun pour les représenter.

Une structure de donnée que j'apprécie beaucoup, c'est le tableau associatif dans son implémentation en php. C'est une structure très souple. Elle permet d'accepter un nombre illimité et indéfini à la base d'élément. On peut faire facilement des tableaux de tableau pour complexifier la structure de donnée. On peut mélanger les différents type que l'on place dans ces tableaux. On peut stocker ou aller chercher des données par indice ou par association.

De plus, le langage php comporte une multitude de fonction qui permettent de manipuler les données, de les trier, de fusionner les tableaux de séparer les clé des valeurs.

L'idée présentée ici est de stocker dans un format accessible par le web une structure de donnée telle que le tableau associatif php.

Une idée qui me vient est d'utiliser un format xml du genre des plist apple, avec une strcuture du genre clé=>valeur avec un nombre indéfini de ces clé. Cette structure est très proche de la structure du tableau php associatif.

Dans OpenSocial, google propose d'utiliser AtomPub comme format d'échange et donc de n'utiliser que des champs standard d'Atom pour représenter la structure de donnée clé=>valeur.

Ainsi, c'est le champs Atome:title qui est utilisé comme clé et le champs Atom:content qui est utilisé comme valeur. Ces 2 champs sont des enfants direct de Atom:entry. Il est possible de mettre un nombre d'entrée (entry) illimité. Donc, ainsi on a réalisé notre tableau associatif. De plus, dans un format atom, il y a une foule de méta données qui sont également envoyé sur l'identité de la source et les dates de création/modification de chaque entrée. Ce qui est très utile pour gérer les conflits de mise à jour d'une application qui utiliserait ces données.

structure REST

Le web est conçu de manière très pratique. La révolution du web est surtout due à la possibilité de pouvoir accéder facilement a des documents aux 4 coins du monde qui sont sur des serveurs différents fourni par des machines différentes. Le web c'est donc, des URL, des adresses qui permettent d'accéder universellement à des ressources, des documents html qui décrivent des ressources document et qui permettent de lier des autres ressources. Ainsi que le protocole http qui permet de transférer les pages.

Il est donc facile sur le web de stocker des pages web (logique!) donc des documents, aussi des images, et quelques formats média (plus compliqué). Il existe aussi toutes sortes de fichiers pour faire de la mise en page et des scripts en tout genres.

Le web est utilisé principalement pour aller chercher des données statiques dans un système de fichier. Mais il peut faire plus. Hormis les requêtes GET Http est également conçu pour faire des requêtes POST, PUT, DELETE, et certainement un foule d'autre pour autant qu'on les définisse.

Le but est donc de pouvoir faire du stockage d'éléments créé dynamiquement et de les poser à l'autre bout du monde avec la simple utilisation d'une url.

Ex: je veux stocker un tableau php que j'utilise dans mon application. Hop, je le sérialise sous une forme xml clé=>valeur, je stocke tout ceci dans une base de donnée, dans une table qui s'occupe de la gestion des méta-données.

Quand je veux le récupérer mon tableau, j'appelle une url particulière avec l'id de mon objet, il ressort sous forme de description xml. Avec simpleXML, en php, il est très facile de recréer mon tableau associatif à partir des données xml.

Système de fichier web

Le système d'url est calqué sur la forme du système de fichier des ordinateur unix. C'est une arborescence. Cette arborescence est étendue en la mélangeant avec des noms de domaines, mais reste une arborescence.

Actuellement, de plus en plus on observe l'émergence de système de classement de donnée par mots-clés plutôt que par arborescence. L'idée est donc ici de créer un véritable système de fichier web basé sur l'utilisation de mots-clés.

Un mot de plus à ajouter au vocabulaire http, pourrait être TAG. Il devient ainsi possible de faire une requête sur une url avec des mots-clés et d'obtenir tous les éléments qui correspondent à la requête. C'est un moyen de retrouver l'efficacité de la recherche que l'on a avec une base de donnée. Car en fait, c'est bien la base de donnée que l'on va faire travailler là. J'ai dis plus haut que l'on fait un stockage des données dans une base et que l'on peut y ajouter des méta-données. Les mots-clés font partie de ces méta-données.

En ce qui concerne le tagging. Ce n'est pas encore très clair dans mon esprit. Faut-il forcer à ce que chaque ressource ait la possibilité d'être taggué quand on lui demande via une requête TAG, ou faut il laisser le tagging à un service fait exprès pour ?

L'avantage su service fait sur mesure est que n'importe quelle URL, donc n'importe quelle ressource peut être taggué sans qu'elle soit faite pour ! (va tenter de faire un tag sur une image !)

Ensuite, comme il existe plusieurs moteurs de recherche (malgré le quasi monopole de google), il peut exister plusieurs moteur de tagging de ressource. C'est exactement ce que fait le service del.icio.us. Chaque URL est classée via des mots clé. De plus, cette application utilise la folksonomie pour unifier les catégories de classement entre des milliers d'utilisateurs.

Donc pour retrouver une ressource on va utiliser ce moteur de recherche/tagging.

En ce qui concerne la normalisation du schéma de requête, google a défini quelques normes... peut être peut on s'en inspirer ??

Toute les requêtes commence par ?q=

Attention à l'écriture concurrente de données !! Chez google on résout le problème en utilisant un numéro de version dans l'uri indiqué dans le document atom. Voir les exemples de mise à jour.

<link rel="edit" href="http://example.com/myFeed/1/2/"/>

L'idée est de créer une horloge logique répartie. On pourrait aussi utiliser la date de modification d'un document. Google ne le fait pas pour des raisons que je n'ai pas trop comprise (fonctionne pas avec DELETE).

Bref, tout ça pour dire qu'il faut penser à la concurrence d'écriture des données dans l'implémentation de l'application.

Authentification

L'authentification reste un problème. Il faut penser à prévoir un service d'identification des utilisateurs et de gestion des droits de ceux-ci sur les ressources. Il est donc probable que pour chaque requête, l'utilisateur doivent décliner ses login/motdepasse. Système que l'on peut simplifier, comme dans n'importe quelle application web, avec l'utilisation d'une clé de session. (dans un cookie ou non)

Il semble que des initiatives commence à voir le jour pour normaliser les protocoles d'authentification entre plateforme web. Ainsi OAuth est peut être une piste à creuser. Cette API est par exemple utilisée sur un service pour s'authentifier sur un autre. (ex: récupération de son carnet d'adresse sur gmail pour vérifier si des amis sont présents sur facebook).

Url sémentique

Le but est d'avoir des url compréhensibles. De pouvoir obtenir des infos rien qu'en écrivant des url. De piloter l'application par les url. Tout est accessible en service web. Il est possible de choisir quel format l'on désire utiliser. HTML pour l'affichage humain.. ou Atom pour une machine. Voici donc quelques exemple et idée pour faire une structure valable.

Obtenir un élément

• http://extremefondue.ch/document/123
• http://extremefondue.ch/image/123
• http://extremefondue.ch/objet/123
• http://extremefondue.ch/utilisateur/123
• http://extremefondue.ch/evenement/123
• http://extremefondue.ch/article/123
• http://extremefondue.ch/news/123
• http://extremefondue.ch/blog/123

Ajouter un élément (différentes possibilités... choisir la meilleure)

• http://extremefondue.ch/add/document/
• http://extremefondue.ch/document/action:add
• http://extremefondue.ch/document/add
• http://extremefondue.ch/index.php?page=document&add ..... c'est réellement la structure

• http://extremefondue.ch/document/?add ... le mieux est de séparer la ressource des actions effectuée sur celle-ci.

Modifier un élément (différentes possibilités... choisir la meilleure)

• http://extremefondue.ch/update/document/123
• http://extremefondue.ch/document/123/action:update
• http://extremefondue.ch/document/123/update
• http://extremefondue.ch/index.php?page=document&add&id=123 ..... c'est réellement la structure

• http://extremefondue.ch/document/123/?update

.. idem pour delete..

Tagguer un élément (différentes possibilités... choisir la meilleure)

• http://extremefondue.ch/tag/document/123/toto,vache
• http://extremefondue.ch/document/123/action:tag/toto,vache
• http://extremefondue.ch/document/123/tag/toto,vache
• http://extremefondue.ch/index.php?page=document&action=tag&id=123&tag=toto,vache ..... c'est réellement la structure

• http://extremefondue.ch/document/123/&tag=toto,vache

Rechercher un élément (différentes possibilités... choisir la meilleure)

• http://extremefondue.ch/search/document/vache,toto
• http://extremefondue.ch/document/action:search/toto,vache
• http://extremefondue.ch/document/search/toto,vache
• http://extremefondue.ch/index.php?page=document&action=search&tag=toto,vache ..... c'est réellement la structure
• http://extremefondue.ch/index.php?page=searche&element=document&tag=toto,vache ..... c'est réellement la structure

• http://extremefondue.ch/document/tag/toto,vache ...ici à nouveau on désigne une ressource par l'intermédiaire d'une recherche

Dans ce cas, il faut choisir si l'on veut une liste de ressources ou directement les ressources elles-même !!! On peut donc faire 2 requêtes différentes.

• http://extremefondue.ch/document/tag/toto,vache ... retourne toute les ressources qui correspondent
• http://extremefondue.ch/document/taglist/toto,vache .. retourne la liste des ressources qui correspondent

Il est aussi possible de représenter cette recherche en séparant les mots-clés par des /

• http://extremefondue.ch/document/tag/toto/vache ... retourne toute les ressources qui correspondent
• http://extremefondue.ch/document/taglist/toto/vache/dromadaire qui ne manque pas d'air/ .. retourne la liste des ressources qui correspondent

La solution est donc bel et bien de séparer la désignation de la ressource grâce à une url propre, et l'action que l'on veut faire sur la ressource. Une pure application REST fonctionne par le protocole HTTP. Les actions ne sont pas dans l'url. Les actions sont directement dans la requête http. Ici, pour des raisons de commodité des outils utilisés, on fourni les actions par le mécanisme des paramètres.

URL humaines..

Dans le cas décrit ci-dessus, une ressource est localisée à une url, puis elle est un type d'élément et possède un id. Ce qui identifie très bien et de manière unique toutes les ressources. Cependant, ce n'est pas très pratique pour un humain de se souvenir de l'adresse ou plutôt de différentier l'article 23 et le 27...... un nom est plus humain.

Dans cette structure, tous les éléments ont des métadonnées obligatoire qui sont le nom, la date de création et la date de modification. Il est donc possible de combiner ces informations pour faire une adresse humaine.

Ainsi, une adresse de base suffisante pour désigner une ressource peut être complétée pour indiquer à un humain de quoi il n'agit et proposer une extension de fichier qui peut être utile pour certaine applications.

• http://extremefondue.ch/document/123
• http://extremefondue.ch/document/123/balade dans la nature.html

Vue que ce qui est dérrière l'id n'as pas d'importance, on peut y mettre n'importe quoi et être certain que les accents et espace ne gênes pas ! Mais comme ça peut être déroutant... il est possible de faire une version sans espaces.

• http://extremefondue.ch/document/123/balade-dans-la-nature.html

Communication entre machines

Ensuite, il est possible à des humains d'avoir des ressources. Cependant, pour des machines c'est plus compliqué. L'HTML n'est pas un format facile à comprendre. il faut prévoir plusieurs vues possibles de la même ressources.

Nous avons donc:

• la vue html qui est la vue standard
• la vue Atom qui est celle compréhensible par les agrégateurs de flux et plus généralement par les machines.
• la vue JSON qui est directement interprétable par une application javascript.
• des formats spécifiques à la ressource tel que vcard, vcalendar,

Ces différente vue sont obtenues en passant en paramètre l'option &output=atom ... par exemple.

AtomPub

Hormis la machinerie web pour manipuler des ressources, il est possible de définir un protocole externe pour que des machines puisses manipuler des ressources. Il est ainsi possible de faire des logiciels de bureau et des services web pour manipuler des données.

De nombreux essais sur des plateforme de blog on fait évoluer l'idée pour arriver jusqu'au protocole AtomPub.

voir l'idée avec AtomAPI

Utiliser Atom comme format, et faire un vrai services REST avec les requêtes HTTP GET, POST, PUT, DELETE pour manipuler les ressources. Voilà en gros l'idée.

Ensuite, il faut voir comment implémenter la machinerie, et voir s'il est possible faire cohabiter des interfaces web et un services atompub sur les mêmes url !

En mélangeant encore un peu d'ajax, le tout devient très intéressant.

Jquery supporte les requêtes ajax HTTP put et delete, mais pas dans tous les navigateurs (lesquels?)

Authentification

Il peut être utile de pouvoir restreindre l'accès à certaines ressources. Donc il faut un moyen d'authentifier des utilisateurs. Comment faire avec des ressources accessible via AtomPub ?

Voici un article à ce propos:

http://www.xml.com/pub/a/2003/12/17/dive.html

L'idée est d'utiliser un système d'authentification décrit ici: http://www.oasis-open.org/committees/wss/documents/WSS-Username-02-0223-merged.pdf

...... après de nombreuses réflexion est de nombreux remaniement... voir l'étude concrète de la création d'une application presque REST..