Je n’ai pas été assez vigilant sur la qualité de l’info (et je ne suis pas très au courant de ce qui se passe chez Mozilla)… Bref, j’ai masqué l’article. Désolé !
J’ai créé cet outil inspiré “Join Together” du début des années 2000, qui combinait des pistes iTunes avec des technologies déjà obsolètes.
J’aurai bientôt un article sur mon blog pour expliquer comment il était possible de supporter l’application Musique de Catalina en maintenant la compatibilité avec iTunes.
Mais du coup je reste un peu sur ma faim si “Chronograf : Visualiser ses données-temps InfluxDB” m’explique juste comment installer et connecter Chronograf à InluxDB, sans m’expliquer les cas d’usage, à quoi ça sert concrètement (https://docs.influxdata.com/chronograf/v1.8/introduction/getting-started/).
J’essaye d’être constructif, ce n’est nullement une attaque personnelle ^^’
Bonjour, oui désolé il manquait un A.
Ma compréhension est que REST définit des principes et RESTful vient ajouter de nouvelles contraintes (idempotence, HATEOAS). Est-ce que ces contraintes sont optionnelles ou bien obligatoire pour la mise en place de RESTful?
Le tuto ZDS https://zestedesavoir.com/tutoriels/299/la-theorie-rest-restful-et-hateoas/ explique les différents niveaux.
Mon sujet initial est que l’article parle de construction d’API RESTful, mais l’API Wikipedia citée n’est pas REST ni RESTful (l’API REST Wiki est https://www.mediawiki.org/wiki/API:REST_API, n’est d’ailleurs pas complètement RESTful)
Concernent l’idempotence, c’est plutôt ça : https://restfulapi.net/idempotent-rest-apis/ du coup toutes les opérations à part le POST sont idempotents; après j’avoue ne pas comprendre toute les nuances décrites dans la page.
Désolé, je ne sais jamais si mon premier message sera lu/répondu, du coup je n’argumente pas dès le premier message,dans une optique de gain de temps :)
Sinon, je ne comprends pas bien ta question ? Car à mon connaissance RESTful est une implémentation du modèle REST et HATEOAS est un composant du modèle REST.
Pour ta question sur l’idempotence, on parle bien de cette notion ( https://en.wikipedia.org/wiki/Idempotence ) ? Si c’est oui, quelle opération est doit idempotente ou non ?
Ha mince… Pas moyen de la dégager définitivement ? Ça arrive de se tromper !
Déjà que ces panneaux me fatigue… Si en plus ils se mettent à moucharder, je risque bien en effet d’avoir très envie de les vandaliser !
Salute,
Pour info “masquer” ne masque l’article que pour toi.
Tcho !
J’ai l’impression que la prez Wanaprez marche pas sur mon iPad…
Je n’ai pas été assez vigilant sur la qualité de l’info (et je ne suis pas très au courant de ce qui se passe chez Mozilla)… Bref, j’ai masqué l’article. Désolé !
Dans tous les cas, on survivra ^^
Tcho !
Ne reste plus qu’à espérer que personne ne l’upvote :-D
Ouais, je me suis retenu de supprimer cet article… putaclic.
Tcho !
Rien de ce qui est dit dans l’article ne corrobore le titre…
ah ba tout n’est pas parfait :)
Oh ! Ça me rappelle quand on faisait des rotozooms sur les 486 :-)
“Certes, l’application Olvid n’est pas encore open source mais l’équipe souhaite qu’elle le soit au plus vite”. Dommage.
Tcho !
Ou on met son script dans un fichier et on l’appelle.
Marche bien aussi.
J’ai créé cet outil inspiré “Join Together” du début des années 2000, qui combinait des pistes iTunes avec des technologies déjà obsolètes.
J’aurai bientôt un article sur mon blog pour expliquer comment il était possible de supporter l’application Musique de Catalina en maintenant la compatibilité avec iTunes.
Ah ouais le temps d’impression est déroutant ! C’est carrément un frein je trouve…
Oups en effet, Chronograf et pas Influx, désolé.
Mais du coup je reste un peu sur ma faim si “Chronograf : Visualiser ses données-temps InfluxDB” m’explique juste comment installer et connecter Chronograf à InluxDB, sans m’expliquer les cas d’usage, à quoi ça sert concrètement (https://docs.influxdata.com/chronograf/v1.8/introduction/getting-started/). J’essaye d’être constructif, ce n’est nullement une attaque personnelle ^^’
Bonjour, oui désolé il manquait un A. Ma compréhension est que REST définit des principes et RESTful vient ajouter de nouvelles contraintes (idempotence, HATEOAS). Est-ce que ces contraintes sont optionnelles ou bien obligatoire pour la mise en place de RESTful? Le tuto ZDS https://zestedesavoir.com/tutoriels/299/la-theorie-rest-restful-et-hateoas/ explique les différents niveaux.
Mon sujet initial est que l’article parle de construction d’API RESTful, mais l’API Wikipedia citée n’est pas REST ni RESTful (l’API REST Wiki est https://www.mediawiki.org/wiki/API:REST_API, n’est d’ailleurs pas complètement RESTful)
Concernent l’idempotence, c’est plutôt ça : https://restfulapi.net/idempotent-rest-apis/ du coup toutes les opérations à part le POST sont idempotents; après j’avoue ne pas comprendre toute les nuances décrites dans la page.
Désolé, je ne sais jamais si mon premier message sera lu/répondu, du coup je n’argumente pas dès le premier message,dans une optique de gain de temps :)
Et si vous utilisez Nix et/ou NixOS , utilisez nix-shell
Un article du même tonneau dans la langue de Shakespear : https://modelpredict.com/python-dependency-management-tools
Hello, je suppose que tu veux dire HATEOAS ? ( https://en.wikipedia.org/wiki/HATEOAS )
Sinon, je ne comprends pas bien ta question ? Car à mon connaissance RESTful est une implémentation du modèle REST et HATEOAS est un composant du modèle REST.
Pour ta question sur l’idempotence, on parle bien de cette notion ( https://en.wikipedia.org/wiki/Idempotence ) ? Si c’est oui, quelle opération est doit idempotente ou non ?
Merci pour tes éclaircissements ?