#webfinger

Et, de la même auteure, orienté cette fois vers les philosophes, son mémoire de #philosophie (master « éthique, écologie et développement durable »), « L’autonomie individuelle et sociale par
rapport aux médias sociaux numériques est-elle une question de justice sociale ? » ▻https://asso.framasoft.org/nextcloud/s/GTiB6oANGSfa5bH#pdfviewer

Pour la v1 de WebFinger, voir ▻http://seenthis.net/messages/6711

Ah super, ça doit renvoyer du #JSON : JSON Resource Descriptor (#JRD).

À noter que le RFC défini aussi une manière de lister des liens web en JSON ! Je ne me fie qu’à ton résumé en français là, mais je suis d’avis que ce point aurait dû être une RFC à part, commune.

Cette norme aurait alors pu être partagée par toutes les #API utilisant JSON comme format (il en existe plein, y compris des semi-normalisés, en draft etc), mais ayant toutes des sémantiques différentes (telle API liste les liens d’une manière, telle autre différemment).

Ça me parait utile, à la manière du projet #JSON-Schema (►http://seenthis.net/messages/174515), qui ne définit pas une sémantique exhaustive, mais seulement des morceaux dédiés à des besoins précis, qu’on assemble ensuite dans un même JSON pour notre cas d’utilisation.

C’est intéressant de dire : désormais si on veut être compatible les uns les autres en JSON, dès qu’on a besoin de liens (quelque soit l’utilisation), on les liste comme ça.

En tout cas, moi je me le note pour ma prochaine utilisation de JSON. :)

#rest

J’ajoute aussi que je trouve souvent plus intéressant de définir une sémantique qu’un format (unique).

Il aurait été possible de dire que le format par défaut (= quand a rien spécifié sur ce point dans la requête) est du JSON, mais qu’il est éventuellement possible d’ajouter un paramètre demandant autre chose (par exemple du YAML).

Tous ces formats de sérialisation sont, en grande partie, compatibles, pour toutes les infos classiques en tout cas : 99% du temps on s’échange des tableaux clés-valeurs ou des listes, hein…

Dans ce contexte (multi-formats) je trouve donc bien qu’il y ait des normes dictant des sémantiques (tel mot pour tel sens), mais sans imposer de format dans la même norme (au contraire d’Atom qui défini les deux en mêmes temps). De cette façon, quelque soit le format, on utilise les mêmes mots.

@rastapopoulos On peut. WebFinger est du REST donc du HTTP donc la négociation de contenu standard fonctionne. Voir l’exemple à la fin de mon article où on demande du XML.

Mea culpa oui, je n’avais pas encore lu jusque tout au bout. :)

Mais c’est plus ou moins ça, car dans « jrd » le « j » veut dire « JSON » forcément. Donc on peut effectivement demander un autre format au service webfinger, mais ça ne correspond pas à mon « souhait » de voir une séparation entre la sémantique (ou syntaxe ou langage) et le format. Et surtout d’avoir une même syntaxe (une même liste de noms de propriétés quoi) mais appelable en plusieurs formats.

En gros une syntaxe commune « rd » (pour ce cas là) et on demanderait alors « rd+json » ou « rd+yaml », etc. Le tout étant d’avoir immédiatement un langage commun une fois qu’on a désérialisé le truc dans son langage de programmation de prédilection.

(J’ai la même réflexion pour ce qui est de décrire une ou plusieurs ressources complètes, comme avec Atom.)

voir aussi #thimbl qui enrichit le #finger d’un .plan contenant des messages récents

> finger @identi.ca@any.io
> finger recifs@twitter@any.io
> ►http://finger.any.io/fil@rezo.net