@gerard94 m’a aidé à mettre en place un deuxième nœud WotWizard. Le serveur html classique (wwClient) est disponible à l’adresse : https://wotwizard.coinduf.eu/
Il effectue des requêtes GraphQL en local au serveur WotWizard (wwServer). L’objectif est de construire un client qui effectue directement des requêtes GraphQL auprès du serveur, je l’ai donc rendu accessible à l’adresse : https://wwgql.coinduf.eu/.
Ce serveur fonctionne bien, on peut par exemple faire une requête avec l’extension RESTer. La requête suivante :
J’ai ensuite essayé de mettre en place un playground GraphQL comme l’a fait@elois afin de faciliter le développement d’un client. Il est disponible à l’adresse https://ww2.coinduf.eu/, mais je n’arrive pas à le configurer.
Par défaut, il envoie une requête au format json :
{"operationName":null,"variables":{},"query":""}
plutôt qu’un formulaire au format x-www-form-urlencoded. Je ne trouve pas comment faire dans leur doc, est-ce que quelqu’un a plus d’expérience avec cet outil ou de meilleures compétences de bidouille que moi ? @poka, comme ça ce sera plus pratique si on veut faire des requêtes GraphQL à WotWizard dans Ğecko
J’avais pas lu ton post dsl. En fait c’est normal, c’est conforme aux specifications GraphQL. Le serveur wotwizard doit supporter ce format sinon il n’est pas conforme.
Ben en fait non. Tu fais du REST là et pas du GraphQL, c’est le serveur qui ne respecte pas les standard
@gerard94 ça confirme ce que je pensais : il y a un standard et nous sommes en dehors ! Ce serait bien de changer ça dans la prochaine version de WotWizard. Il faut changer wwServer, wwClient, la doc, et les clients que j’ai commencé à écrire
Peux-tu préciser dans quel document se trouvent ces spécifications s’il te plaît ? Il ne me semble pas les avoir vues dans la notice officielle, mais je peux me tromper.
J’ai bien vérifié dans les dernières spécifications officielles de graphQL. Le terme “operationName” n’en fait pas partie. C’est juste un nom de variable utilisé dans la description de trois algorithmes. Il n’est jamais dit comment le nom de l’opération à effectuer devait être transmis, ni comment ce paramètre devait être nommé.
To execute a request, the executor must have a parsed Document and a selected operation name to run if the document defines multiple operations, otherwise the document is expected to only contain a single operation.
J’ai implémenté les requêtes graphql pour GVA dans duniterPy.
Elle sont de ce type :
Content-Type = « application/json »
body =
{"variables":{},"query":""}
Je ne supporte pas encore le paramètre « operationName ».
Les requêtes graphQL sont indépendantes du protocole de transport. Elle sont contenue ici dans le body en json, ce qui semble être la norme, une « convention », quand le protocole de transport est HTTP.
Le sujet ici n’est pas le protocole graphQL, mais le protocole de transport. Il est libre, donc tu peux utiliser les POST HTTP avec le formulaire HTTP urlencodé. Mais tu seras le seul… Car tu ne suis pas la norme établie par « convention » pour le protocole HTTP.
Mais on pourrait très bien faire un serveur et un client graphQL avec un transport en socket réseau envoyant des paquets binaires, du moment que dedans on retrouve les infos de la requête : query, variables, et, semble-t-il, en option, « operationName ».
Conclusion : il faut adapter l’outil graphQL playground pour le mettre en conformité avec wotwizard si on veut un terrain d’essai pour faciliter l’interaction avec cette API.
Nous ne nous sommes pas compris, je ne parle pas du champ operationName mais du fait de vouloir envoyer une requête GraphQL au format x-www-form-urlencoded.
Personne ne fait ça et c’est juste impossible si on veut utiliser GraphQL pleinement (avec des variables des fragments et des directives)
Non car dans ce cas aucun dev front ne pourra utiliser de lib graphql existante pour taper dans l’API de WotWizard. C’est le serveur qu’il faut adapter, et non pas un client en particulier !
Au-delà des spec écrites, il y a les usages ultra rependu mais non spécifiées formellement, les «spec implicite», tout aussi importantes à respecter si or veut de l’interopérabilité.
Je fais tout ça couramment. Je ne comprends pas ce que tu veux dire. Jette un coup d’œil à la partie “GraphQL requests, and their meanings” du manuel de WotWizard (les fragments et les directives sont inclus dans le champ de la requête graphQL – “graphQL”, les variables sont dans un autre champ – “valVals”) :
En fait le format x-www-form-urlencoded a exactement les mêmes fonctionnalités qu’un objet JSON.
Je maintiens que mon implémentation de graphQL est totalement conforme aux directives officielles. Maintenant, chacune a ses particularités et la mienne n’a pas les mêmes que celle que tu utilises. Il y en a d’autres. Par exemple, j’utilise l’extension de Firefox “RESTer” qui permet d’utiliser le format et les noms de variables de WotWizard. Je ne pense pas que les particularités de la bibliothèque que tu utilises soit devenues un standard. J’ai vu d’autres bibliothèques en Go implémentées autrement.
Qui comme son nom l’indique est conçue pour les API REST…
Ce ne sont pas des particularités de “ma” lib, ça vient du playground et de l’écosystème js en général. Je me suis adapté coté serveur, car mon objectif est de faire une API compatible avec un large spectre de lib «client» utilisées par les dev front.
Je ne vois pas l’intérêt de faire une API GraphQL si les gens qui souhaitent l’utilisée sont obligés de coder à la main la manière spécifique dont wotwizard attend les requêtes.
Le problème avec le Playground est bien la preuve que ton serveur ne supporte pas les usages répandus, essaye donc d’utiliser ton API avec une lib graphql en Js ou en Dart
Je ne crois pas. J’ai vu d’autres choses. Mais merci de ton avertissement. C’est vrai que les premières implémentations tendent à imposer une jurisprudence, mais il y en a encore, me semble-t-il, beaucoup de différentes.
Rester est un client REST, pas graphQL. Or le playground suit la tendance moderne (qui date de plusieurs années quand même) de tout passer en json dans le body. C’est l’usage le plus répandu en javascript, bien plus facile à gérer que les formulaires urlencodés dont l’usage baisse avec la disparition des sites à l’ancienne. Impossible de s’en passer pour faire une « one page app ».
Tu as dit toi même ne pas être un expert du HTML/javascript. En ayant bouffé depuis 1994, je peux t’assurer que la bonne pratique est l’usage intensif de json.
Le playground graphQL est « clef en main » si tu fais « comme tout le monde ». Faire autrement c’est, plus de travail pour les autres, et c’est donc de facto réduire les contributions côté client. Bref je plussoie ce que dis Elois.
Car tu ne suis pas la norme établie par « convention » pour le protocole HTTP.