Reprise du message précédent :

Non.

Non plus, pour aussi bien la raison que tu indiques (la balise sert également à indiquer que l'URL est bien le point d'entrée d'une plage) que le fait que ça encode des informations d'URL dans la spec, si Roy Fielding était là il te balancerait par la fenêtre.

Et ça n'a rien de "simpliste" comme comportement, ça a au contraire des implications fortes (ça empêche un point d'entrée statique qui dirige vers une CGI en C). Le gain est faible, on perd en clarté, on perd en flexibilité et on perd la dynamique URL-based. Ca m'emmerde déjà de pas avoir réussi à encoder les méthodes authorisées dans le lien, je tiens pas à partir sur du RPC alors que je voulais tenter une spec REST.

Tu peux expliquer ça ?

Une URL de soumission de bouteille par défaut, c'est une URL encodée dans la spec (comme étant équivalente au point d'entrée du service), alors qu'il n'y a aucune raison de le faire puisqu'il est trivial de fournir cette URL dans le document fourni par le point d'entrée.

Rien ne t'empêche par la suite de cacher cette URL et de taper directement dedans, mais c'est un détail d'implémentation et si ça pète c'est ton problème d'implémenteur

OK, donc c'est là où j'ai pas été clair. Dans ma proposition, l'url est de soumission est le point d'entrée (et n'a donc pas besoin d'être fournie par ce dernier).

Ca ne change en rien ma réponse. Le point d'entrée d'un service c'est la ressource permettant de se déplacer dans les collections du service. Une ressource qui demande des informations n'est pas un point d'entrée et une ressource qui ne fournit pas d'informations n'est pas un point d'entrée. Après tu peux réutiliser l'URL pour des interactions (cf ma note 2), mais ça ne change rien au problème.

ok.
Effectivement, en prenant en compte ton idée de point d'entrée qui te fournis les infos sur comment utiliser le service (et ce qu'il fournis (extensions...)), le fait d'utiliser <link> est totalement logique.
 
par contre, pour le nom du rel, je verrais plus un truc comme openid : <link rel="beach.throw-bottle" href="http://foo.bar" />

throw est effectivement mieux que send, par contre le préfixer ça part dans l'architecture astronautique. On en a strictement pas besoin pour un truc pareil qui va être utilisé (au mieux) par 2 pelés et 3 tondus sur une page unique

enfin, le principe c'est tout de même d'avoir plein de plages, sinon l'intérêt est assez limité.

Ben dites donc, c'est de la résurrection ou je ne m'y connais pas ^^
 
Enfin, c'était bref mais intense
 
Vous êtes arrivés à une conclusions du coup pour faire une nouvelle RFC ?

Aloha,
 
J'ai une première implé, qui pour le moment ne fait rien d'autre que ce dont on a discuté. Ceux qui veulent tester : http://beach.leriton.net
Retours, suggestions, trous de sécu...
 
Je résume :
 

• la homepage avec une balise link, le rel à "throw-bottle" et l'url qui va bien
• si on attaque l'url de soumission autrement qu'en post => 405 method not allowed
• si le message est nul ou vide => 400 bad request
• on choppe la plage d'envoi dans le header x-current-from si il est présent

Pour le moment, stockage des bouteilles uniquement. Tout reste à faire en quelque sorte.

Ca a pas l'air de marcher très bien depuis chez moi:

>>> from urlparse import urljoin
>>> from urllib2 import urlopen
>>> from urllib import urlencode
>>> domain = 'http://beach.leriton.net/'
>>> path = '/bottle/throw'
>>> url = urljoin(domain, path)
>>> url
'http://beach.leriton.net/bottle/throw'
>>> urlopen(url, urlencode({'message':'je peux test?'}))
 
Traceback (most recent call last):
  File "<pyshell#7>", line 1, in <module>
    urlopen(url, urlencode({'message':'je peux test?'}))
  File "e:\python25\lib\urllib2.py", line 124, in urlopen
    return _opener.open(url, data)
  File "e:\python25\lib\urllib2.py", line 387, in open
    response = meth(req, response)
  File "e:\python25\lib\urllib2.py", line 498, in http_response
    'http', request, response, code, msg, hdrs)
  File "e:\python25\lib\urllib2.py", line 425, in error
    return self._call_chain(*args)
  File "e:\python25\lib\urllib2.py", line 360, in _call_chain
    result = func(*args)
  File "e:\python25\lib\urllib2.py", line 506, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
HTTPError: HTTP Error 422: Unprocessable Entity
>>>

L'url est bonne, en get elle renvoi bien un 405 (pour moi en tout cas).
 
Eeeeet, test en post me renvoi la même chose que pour toi !
 
Ca apparaissait qu'en prod, c'est corrigé, et cette fois ci, tu peux test
 
Merci du retour !

Ok, ça renvoie une 201 et normalement t'as reçu une bouteille de ma part (enfin 2, mais une seule signée)
 
Par contre urllib2 est con, il lève une exception sur une 201

Bon, résumons.
 
Nous avons donc deux entités:
 1/ bouteille.
    Une bouteille est composée uniquement d'un message.
    Ce message est du text/plain encodé en UTF8 [1]
    Il n'y a aucune notion de date ou d'auteur de message. Libre à l'auteur du message de le signer et/ou de la dater.
 
 2/ plage.
    Une plage est juste un lieu où se trouvent un certain nombre de bouteilles.
    Une plage est identifiée par une URI.
 
Maintenant, le but est donc de faire transiter (semi-)automatiquement des bouteilles d'une plage à une autre. Seules les plages peuvent se parler entre elles. Les bouteilles sont des objets passifs qui ne font que transiter de plage en plage. Une bouteille, pour être ouverte et son message lu, doit sortir de sa plage actuelle. Elle peut ensuite être refermée et remise dans le circuit.
 
Il est maintenant convenu que le protocol sera basé sur http(s) (et donc RESTful).
 
Les méthodes disponibles seraient (à discuter) dont:
 */ nom et version de la plage:
   */ méthode (au sens applicatif du terme): URI/version
   */ méthode http: GET
   */ résultat: au choix de l'implémentation. De préférence en text/plain UTF8.
 
 */ liste des plages connues:
   */ méthode: URI/known-beaches
   */ méthode http: GET
   */ résultat: liste d'URI. une par ligne
 
 */ prendre une bouteille sur une plage:
   */ méthode: URI/get
   */ méthode http: GET
   */ résultat: le message de la bouteille
 
 */ lancer une bouteille à la mer:
   */ méthode: URI/throw
   */ méthode http: POST
   */ Header: Referer: On reprend l'idée de Masklinn mais on réutilise ce qui existe déjà. La plage, si elle garde la bouteille) doit vérifier l'exactitude de ce champs pour vérifier que c'est bien une plage (l'utilisation de la méthode /known-beaches est recommendée, de manière à permettre la propagation des plages). Il est recommendé que les clients laissent ce champs vide.
   */ content-type: application/x-www-form-urlencoded
   */ paramètres:  
      */ message=
      */ format= [1]
   */ résultat: au choix de l'implémentation.
   */ note: une plage peut décider de garder la bouteille ou de la transmettre à une autre plage. Dans ce cas, le Header "Referer" peut être altérer pour permettre la propagation des plages.
 
Sur ce, j'attend vos commentaires.
 
P.S.: L'idée de Masklinn d'utiliser la balise <link> n'est pas à jeter non plus. Cela peut être utile couplé à une extension firefox (ou un script greasemonkey) qui permet de proposer un formulaire html sur tout les pages web contenant cette balise.
 
--
[1] Accessoirement, le message peut être sous un autre format. Ce format est alors déterminé par la première ligne du message qui doit être

où "xxx" représente le format. Exemples de formats: html, rst, base64/png, url
Après, libre au plages clients, d'interpreter ou non ces formats
 
--
Edit: certaines corrections...

Je vois pas l'intérêt de ces trucs, non seulement c'est du RPC (alors que je le répète mon but était un truc RESTful) mais toutes les communications entre les plages sont déjà rendues possibles par la spec initiale...

Pas vraiment non, SOAP tourne sur HTTP et est anti-RESTful au possible

LeRiton t'es dans le coin? Ta plage peut test ou pas?

En théorie oui.
 

Cool, j'ai plus qu'à décider de la manière dont je vais configurer le job et tu vas recevoir plein de messages (vu que t'as la seule plage avec laquelle la mienne peut communiquer )

Incroyable, deux plages en seulement quelques mois    
 
J'vais pouvoir attaquer la partie client su je comprend bien...

 
Cron job créé, normalement ta plage va recevoir 1 bouteille/jour jusqu'à ce qu'il n'y en ait plus chez moi

Comment tu (vous ? on est toujours seuls ?) gère la détection d'url absolue / relative ?
 
On peut considérer qu'une url relative est tout ce qui commence par '/', on inclue aussi le point et les deux points, ou il faut gérer d'autres cas si on veut faire les choses proprement ? Le slash et le point me semblent suffisants.
 
Les bouteilles arrivent, y'a pas de soucis. Ce qui est génial, c'est qu'elle pourront faire du ping-pong entre nos deux plages dés que j'aurais terminé
 
C'est vraiment un projet d'envergure

Dans quel cas/à quel endroit?

Enfin globalement je gère rien du tout perso, je code en Python, donc j'appelle urlparse.urljoin et il se démerde tout seul pour comprendre ce qui se passe

Dans l'envoi d'une bouteille, la récupération de l'URL à laquelle balancer le truc donne ça:

def _get_dest(self, connection, url):
    response, content = connection.request(url)
    soup = BeautifulSoup.BeautifulSoup(content)
    link = soup.find('link', rel='throw-bottle')
 
    if link != None:
        return urlparse.urljoin(
            url, link['href'])

connection est la connection HTTP, url est le point d'entrée de la plage distante

OK, la doc d'urljoin répond à ma question, spécialement cette partie :

urljoin('http://www.cwi.nl/%7Eguido/Python.html',
...         '//www.python.org/%7Eguido')
'http://www.python.org/%7Eguido'

Plus qu'à me caler là dessus ou trouver l'équivalent en Ruby.

Pour info sinon, les derières bouteilles que j'ai reçu de ta part :

J'ai pas les dates sous les yeux.

Edit : bin y'a URI.join()

Le projet a du succès, c'est un fait.
 
Maintenant, je me pose la question de savoir si les 13 pages dont 10 inutiles depuis la nouvelle RFC (perdue dans le lot) plus un premier post pas à jour ne joue pas un peu dans le fait qu'on tende plus vers Berk plage que les atolls ? On a l'air d'avoir perdu KangOl dans la discussion en plus
 
Un thread tout frais remettrait peut-être les choses dans l'ordre, avec pub, tits pour attirer le chalant, le tout avec un premier post tout frais made in Masklinn.

Alors que les 2 plages existantes sont en Python et en Ruby?

 
   
 
Les cat' Python et Ruby sont pas exactement les plus fréquentées... Mais je note que t'as pas dit non.

Salaud leriton tu me renvoies mes bouteilles

Ha bon ?!?
C'est pas en prod pour le moment, donc si je t'ai renvoyé quelque chose, c'est que mes tests sont pas étanches

Normalement il y a 2 bouteilles qui sont retournées chez toi que je ne me souviens pas avoir balancé sur ma plage, et une qui ressemble pas mal à du test

Non.
J'ai juste un peut du mal avec la version REST qui, selon moi, n'a aucun intérêt, à part d'être buzzwordé (c'est même plus contraignant, vu qu'il faut parser une page html (même s'il y a des libs)).
 
Bon, vais voir pour un second client python...

C'est bien ça l'intérêt . Avec la réduction de la taille de l'interface aussi (vu qu'on passe d'une demi-douzaine de méthodes RPC à un point d'entrée et 2 content-types)

Faut pas abuser non plus

Cool, ça vie encore.
Pas cool, j'ai même plus de site web pour tester ma future plage (tout pété pour le moment de toute manière).

Et de presque troize  \o/
 
J'ai un client presque prêt, faudrait sévèrement que je me sorte les doigts d'où ils sont pour le mettre en ligne.

Y'aurait un client php opérationnel, tout prêt à être installé ?

AFAIK il n'y a pas de plage "REST" implémentée en PHP, LeRiton a fait la sienne en Ruby et la mienne est en Python.
 
Faut que je la clean un peu pour pouvoir publier le source d'ailleurs.

Faudra que je pense à ressortir le mien de son cercueil histoire d'en avoir un en .NET aussi... sous Linux évidement.

J'ai mis à jour, avec une jolie mise en page pré-kolkhozienne du meilleur effet. Ça viendra avec le temps.

Si quelqu'un, genre Masklinn, peut test avec un client, juste histoire d'être sûr que la mise-à-jour à pas tout flingué (TDBNSD: Test Driven But Not Safe Development), ça serait super chou.

Edit : http://beach.leriton.net

Y'a un bon potentiel pour faire de la pub mine de rien, quand on y pense un peu, là. Faudra qu'il y ai beaucoup de plages notez bien, mais bon, y'a du potentiel.

Epic bumpage, me faisant chier j'ai repris la plage que j'avais créé initialement, packagé ça proprement avec du setup.py et du requirements.txt (pour pip) et j'ai collé le tout sur bitbucket:

http://bitbucket.org/masklinn/beach/
http://bitbucket.org/masklinn/currents/

C'est en deux partie:

• Beach, la plage même qui reçoit des requêtes et stocke des bouteilles avec urls.py, admin.py & tout le toutim
• Currents, une management command qui sert à envoyer des bouteilles aux autres plages (à coller dans un cron ou autre), qui dépend naturellement de beach.

C'est du python/django, pour l'installation pour beach suffit de mettre l'app dans son settings.py et d'include() beach.urls, pour currents il faut l'installer dans son settings.py et définir un setting SITE_DOMAIN pour pouvoir envoyer l'URL de la plage dans x-current-from.

Beach dépend juste de Django, Currents dépend de Beach, httplib2 et BeautifulSoup (c'est tout marqué dans les requirements.txt de toute façon)