IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

PostgreSQL Discussion :

PostgREST : un serveur web autonome qui fournit une API RESTful à partir de n'importe quelle BD PostgreSQL


Sujet :

PostgreSQL

  1. #1
    Chroniqueur Actualités
    Avatar de Bruno
    Homme Profil pro
    Rédacteur technique
    Inscrit en
    mai 2019
    Messages
    1 215
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : mai 2019
    Messages : 1 215
    Points : 24 379
    Points
    24 379
    Par défaut PostgREST : un serveur web autonome qui fournit une API RESTful à partir de n'importe quelle BD PostgreSQL
    PostgREST : un serveur web autonome qui fournit une API RESTful à partir de n'importe quelle base de données PostgreSQL,
    il permet de contourner les ORM

    PostgREST est un serveur web autonome qui transforme votre base de données PostgreSQL directement en une API RESTful. Les contraintes structurelles et les permissions de la base de données déterminent les points de terminaison et les opérations de l'API.

    Selon ses concepteurs, l'utilisation de PostgREST est une alternative à la programmation manuelle CRUD. Rappelons que l'acronyme informatique anglais CRUD (pour Create, Read, Update, Delete) désigne les quatre opérations de base pour la persistance des données, en particulier le stockage d'informations en base de données.

    « PostgREST est performant, stable et transparent. Il nous permet d'amorcer des projets très rapidement et de nous concentrer sur nos données et notre application au lieu de construire la couche ORM. Dans notre cluster k8s, nous exécutons quelques pods par schéma que nous voulons exposer, et nous augmentons/réduisons en fonction de la demande. Nous ne pourrions pas être plus heureux », déclare Anupam Garg de Datrium, Inc.

    Nom : PostRest.jpg
Affichages : 68701
Taille : 18,4 Ko

    L'écriture de la logique métier entrave souvent la structure de la base de données. Le mapping objet-relationnel est une abstraction peu fiable qui conduit à un code impératif lent. La philosophie PostgREST établit une seule source déclarative de vérité : les données elles-mêmes.

    PostgreSQL, un système de gestion de données connu pour sa fiabilité et sa robustesse, bénéficie de plus de 25 ans de développement open source par une communauté mondiale de développeurs. Il s’agit de l'un des systèmes de gestion des bases de données open source les plus avancés. Il est riche en fonctionnalités, avec des types de données robustes, une indexation puissante et un large éventail de fonctions intégrées que peuvent être utilisé pour simplifier la pile de données et permettre aux développeurs de se concentrer sur la création de son application.

    Le PostgreSQL Global Development Group a annoncé le 13 octobre la sortie de PostgreSQL 15, qui s'appuie sur les améliorations de performance des versions récentes avec des gains notables pour la gestion des charges de travail dans les déploiements locaux et distribués, notamment un tri amélioré. Une version aui améliore également l'expérience du développeur avec l'ajout de la populaire commande MERGE.

    Programmation déclarative

    Il est plus facile de demander à PostgreSQL de joindre des données pour vous et de laisser son planificateur de requêtes s'occuper des détails que de parcourir vous-même les lignes en boucle. Il est plus facile d'attribuer des permissions aux objets de la base de données que d'ajouter des mécanismes de protection dans les contrôleurs. (C'est particulièrement vrai pour les permissions en cascade dans les dépendances de données.) Il est plus facile de définir des contraintes que d'alléger le code avec des contrôles d'intégrité.

    PostgREST a une portée ciblée. Il fonctionne bien avec d'autres outils comme le serveur web Nginx. Cela oblige à séparer proprement les opérations CRUD centrées sur les données des autres préoccupations.

    « J'aime le fait que PostgREST ne fait qu'une chose, et une chose bien. Alors que PostgREST se charge de combler le fossé entre notre serveur HTTP et la base de données PostgreSQL, nous pouvons nous concentrer sur le développement de notre API dans un seul langage : SQL. Cela place la base de données au centre de notre architecture, et nous a poussé à améliorer nos compétences en programmation SQL et en conception de bases de données », Eric Bréchemier, ingénieur données, eGull SAS.

    Avec PostgREST, aucun ORM (Object-Relational Mapping) n'est impliqué. La création de nouvelles vues se fait en SQL, avec les conséquences connues sur les performances. Un administrateur de base de données peut désormais créer une API à partir de rien, sans une programmation personnalisée.

    L’ORM est un type de programme informatique qui se place en interface entre un programme applicatif et une base de données relationnelle pour simuler une base de données orientée objet. Ce programme définit des correspondances entre les schémas de la base de données et les classes du programme applicatif.

    Voici, ci-dessous, quelques avis sélectionnés par l’équipe en charge de PostgREST :

    « Je dois juste dire que l'utilisation du CPU et de la mémoire par rapport à notre API basée sur Node.js/Waterline ORM est ridicule. Il est même difficile de la pousser au-delà de 60/70 Mo alors que notre API actuelle atteint constamment 1 Go en fonctionnant sur 6 instances (dynos) », Louis Brauer.

    « J'ai vraiment apprécié le fait que, tout à coup, j'écrivais des microservices en SQL DDL (et en fonctions JavaScript v8). J'ai évité tellement de textes passe-partout. L'instant d'après, nous avons réécrit entièrement une application Spring+MySQL en 6 mois. Littéralement 10x plus rapide, et le code était super concis. L'ancienne application avait nécessité 3 ans et une équipe de 4 personnes pour la développer », Simone Scarduzio.

    Mettre en place une API RestFull depuis n'importe quelle base de données PostgreSQL

    Source : PostgREST

    Et vous ?

    Que pensez-vous de PostgREST ? L'avez vous déjà utilisé ?

    Peut-on considérer PostgREST comme une plus-value pour PostgreSQL ? Sinon, connaissez-vous des similitudes dans d'autres SGBD ?

    Voir aussi :

    PostgreSQL 15 est disponible, elle améliore de l'ordre de 25 % à 400 % ses algorithmes de tri en mémoire et sur disque, et apporte la populaire commande MERGE

    PostgreSQL : Supabase annone la mise en libre accès de Postgres-wasm, un serveur PostgreSQL qui fonctionne dans un navigateur

    IvorySQL : un PostgreSQL open source compatible avec Oracle, pourrait répondre au besoin de migrer des applications Oracle vers l'open source Postgres
    Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  2. #2
    Membre extrêmement actif
    Homme Profil pro
    Développeur informatique
    Inscrit en
    octobre 2017
    Messages
    1 398
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : octobre 2017
    Messages : 1 398
    Points : 4 693
    Points
    4 693
    Par défaut
    Nous utilisons PostgREST depuis pas mal de temps et il faut dire que la solution est très efficace et particulièrement stable.

    Nous avions une solution basée sur Posgtresql que l'on a décidé de transformer en solution Cloud.

    Nous avons simplement ajouté une couche REST à l'aide de PostgREST sans avoir à changer un bit dans la base de données d'origine.

    Avec plusieurs clients utilisant notre plateforme Cloud depuis plus d'une année, nous n'avons pas eu un seul problème avec PostgREST.

    Par contre pas d'avis sur la dernière version annoncée parce que pas encore testée.

  3. #3
    Expert confirmé
    Homme Profil pro
    Développeur .NET
    Inscrit en
    novembre 2009
    Messages
    1 917
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : novembre 2009
    Messages : 1 917
    Points : 5 221
    Points
    5 221
    Par défaut
    J'ai du mal à comprendre l'avantage de la couche Rest.
    Je vois bien le gain d'exécution à avoir directement la sérialisation en JSON, mais j'ai un peu plus de mal à avoir l'appel direct aux données. Intuitivement ça va à l'encontre des bonnes pratiques en vigueur, mais bon j'ai bien conscience que les bonnes pratiques d'hier ne seront plus celles de demain (#fashion).
    Par contre là ou j'ai une grosse interrogation c'est sur l'utilité d'avoir du REST. Quel avantage par rapport à un une requête SQL directement dans un POST ?
    C'est un peu comme s'il fallait encore se farcir un nieme pseudo language (comme https://www.odata.org/), alors qu'ici on pourrait clairement avoir la requête directement.
    Au delà de ça comment sont gérés les requêtes légitimes du pirate qui veut accéder à n'importe quoi?

  4. #4
    Membre extrêmement actif
    Homme Profil pro
    Développeur informatique
    Inscrit en
    octobre 2017
    Messages
    1 398
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : octobre 2017
    Messages : 1 398
    Points : 4 693
    Points
    4 693
    Par défaut
    Citation Envoyé par micka132 Voir le message
    Par contre là ou j'ai une grosse interrogation c'est sur l'utilité d'avoir du REST. Quel avantage par rapport à un une requête SQL directement dans un POST ?
    C'est un peu comme s'il fallait encore se farcir un nieme pseudo language (comme https://www.odata.org/), alors qu'ici on pourrait clairement avoir la requête directement.
    Tu t'évites déjà à devoir faire appel à des driver X ou Y pour permettre la connexion entre le client et la base de données!!! Je peux te dire que lorsque tu as un système hétérogène avec des clients développés pour différentes plateformes et différentes plateformes qui doivent se connecter à ta base de données, c'est un vrai plaisir de remplacer un douzaine de drivers différents (souvent développés par des sociétés tierces dont tu es dépendant) par du REST pour tout le monde.

    Le plus souvent avec ces drivers les échanges de données se font en clair. Avec REST, tu peux sécuriser ton échange de données.

    Citation Envoyé par micka132 Voir le message
    Au delà de ça comment sont gérés les requêtes légitimes du pirate qui veut accéder à n'importe quoi?
    REST n'est que le mode de communication. Ce n'est pas parce que tu utilises REST qu'il faut concevoir sa base de données n'importe comment et en faire un "moulin" ouvert à tous les hackers!

  5. #5
    Expert confirmé
    Homme Profil pro
    Développeur .NET
    Inscrit en
    novembre 2009
    Messages
    1 917
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : novembre 2009
    Messages : 1 917
    Points : 5 221
    Points
    5 221
    Par défaut
    Citation Envoyé par Anselme45 Voir le message
    Tu t'évites déjà à devoir faire appel à des driver X ou Y pour permettre la connexion entre le client et la base de données!!!
    Tu sembles confondre REST et service web (et même peut-être plus largement avec serveur).
    Ma question ne concerne que l'intérêt d'avoir un pseudo langage de requête au lieux de fournir à ce service web directement la requête SQL via POST.

    Peut-être est-ce que ça à voir avec la sécurisation de ma 2eme question.

    Citation Envoyé par Anselme45 Voir le message
    Ce n'est pas parce que tu utilises REST qu'il faut concevoir sa base de données n'importe comment et en faire un "moulin" ouvert à tous les hackers!
    La conception de la BDD n'a pas grand chose à voir dans la sécurisation. Ma question est comment tu empeches le hacker de faire un select * from user, dès lors que l'utilisateur qu'utilise PostgREST pour se connecter à Postgres à bien le droit de le faire.

  6. #6
    Membre expérimenté
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juin 2004
    Messages
    371
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : juin 2004
    Messages : 371
    Points : 1 346
    Points
    1 346
    Par défaut
    Citation Envoyé par micka132 Voir le message
    La conception de la BDD n'a pas grand chose à voir dans la sécurisation.

    Comment ça ?

    Lors de la conception de ta BDD, tu es sensé créer les rôles/logins qui vont avec et les attribuer aux bonnes personnes. La gestion des droits est tout un pan des SGBDR (principalement via GRANT/REVOKE mais aussi avec les row-level-access-control par exemple). Toute personne qui se connecte à une base de données correctement conçue avec le rôle qui lui est attribué peut normalement exécuter n'importe quelle requête SQL sans compromettre la sécurité et les données des autres utilisateurs.

    Maintenant la prudence recommande de ne pas donner directement accès à l'interface SQL aux utilisateurs. Et du coup effectivement présenter des procédures stockées/vues via PostgREST est de mon point de vue mieux que passer des commandes SQL directement via un service REST.

    D'un point de vue architectural également, le client n'a pas à savoir que le service REST utilise du SQL, ce qui permet au responsable du service REST de passer un jour à une autre technologie sans affecter les utilisateurs de son service.

  7. #7
    Membre régulier
    Profil pro
    Retraité
    Inscrit en
    mars 2010
    Messages
    35
    Détails du profil
    Informations personnelles :
    Âge : 53
    Localisation : France

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : mars 2010
    Messages : 35
    Points : 119
    Points
    119
    Par défaut
    Ma question est comment tu empeches le hacker de faire un select * from user, dès lors que l'utilisateur qu'utilise PostgREST pour se connecter à Postgres à bien le droit de le faire.
    En utilisant une procédure stockée que le DBA (responsable de la base de données) aura calibré, ce n'est pas une requête SQL qui passe par le réseau (si c'est cela qui t'inquiète) mais quelque chose du style :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    nom_procedure(critere1, critere2, etc)
    C'est ça qui passe par PostgREST. Du côté de la base de donnée, la procédure stockée aura une requête paramétrée du style (pour les plus simples en lecture):
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
     select * from ? where ? group by ...
    Mais c'est habituellement beaucoup plus chiadé parce que tu y inclus les règles de sécurité et les règles de gestion de l'application de manière totalement invisible pour le client.

    J'utilisais déjà cette manière de faire il y a 25 ans, c'est solide, efficace et simple, surtout quand on bosse avec des intervenants extérieurs..

  8. #8
    Membre extrêmement actif
    Homme Profil pro
    Développeur informatique
    Inscrit en
    octobre 2017
    Messages
    1 398
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : octobre 2017
    Messages : 1 398
    Points : 4 693
    Points
    4 693
    Par défaut
    Citation Envoyé par micka132 Voir le message
    Tu sembles confondre REST et service web (et même peut-être plus largement avec serveur).
    Ma question ne concerne que l'intérêt d'avoir un pseudo langage de requête au lieux de fournir à ce service web directement la requête SQL via POST.

    Peut-être est-ce que ça à voir avec la sécurisation de ma 2eme question.


    La conception de la BDD n'a pas grand chose à voir dans la sécurisation. Ma question est comment tu empeches le hacker de faire un select * from user, dès lors que l'utilisateur qu'utilise PostgREST pour se connecter à Postgres à bien le droit de le faire.
    Je ne confonds rien par contre je peux te dire que ton commentaire démontre que tu ne connais pas ce que tu te proposes de commenter. On ne peut pas tout connaître mais il est toujours utile de rester humble quand on pose des questions dans un domaine où l'on n'excelle pas. Cela évite de passer pour un "coui...on".

    Amitié et tous mes voeux de bonne année pour 2023!

  9. #9
    Nouveau Candidat au Club
    Homme Profil pro
    Webmaster
    Inscrit en
    janvier 2023
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Webmaster
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2023
    Messages : 1
    Points : 0
    Points
    0
    Par défaut
    Je trouve cette librairie extrêmement passionnante, cependant, après une lecture attentive de leur documentation, je reste perplexe sur la couverture de l'ensemble des cas d'usage d'une API.

    Plus particulièrement, imaginons une facture et ses lignes de facture, c'est un ensemble cohérent et dans une API Rest on souhaiterait, lors d'un ajout, pouvoir enregistrer l'ensemble d'une traite en faisant quelque chose du style:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    {
      "number": 4,
      "date": "2011-10-05T14:48:00.000Z",
      "lines": [
        {
          "quantity": 1,
          "product": "Product 1",
          "price": 2.3
        }
      ]
    }
    Comment faire avec PostgREST ? la seule façon que je vois est de réaliser 2 requêtes, une première pour la facture et une seconde avec les lignes de détail, ce qui me gène c'est que si je souhaite réaliser un traitement tel que l'envoi de la facture par mail, j'avais dans l'idée de faire un LISTEN / NOTIFY dans l'application backoffice (pour éviter de devoir faire appel à une autre API une fois la facture enregistrée). La seule méthode que je vois serai donc d'avoir une colonne status qui devrait, une fois les lignes de détail enregistrées, être modifiée (troisième requête) pour pouvoir réaliser une action à cette modification.

    Je trouve que cela est un peu dommage.

  10. #10
    Membre extrêmement actif
    Homme Profil pro
    Développeur informatique
    Inscrit en
    octobre 2017
    Messages
    1 398
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : octobre 2017
    Messages : 1 398
    Points : 4 693
    Points
    4 693
    Par défaut
    Citation Envoyé par la-source Voir le message
    Je trouve cette librairie extrêmement passionnante, cependant après une lecture attentive de leur documentation je reste perplexe sur la couverture de l'ensemble des cas d'usage d'une API.

    Plus particulièrement, imaginons une facture et ces ligne de facture, c'est un ensemble cohérent et dans une API Rest on souhaiterai lors d'un ajout pouvoir enregistrer l'ensemble d'une traite en faisant quelque chose du style:

    ...

    Comment faire avec PostgREST ?
    Ah bon? On ne doit pas vivre dans le même monde!

    La solution est simplissime et en une seule requête, tu peux faire des choses bien plus compliquée!!!

    Une fonction codée dans la base de données Postgresql que tu appelles via PostgREST!!! Et la fonction en question va te retourner un une seule requête l'info sous la forme que tu veux, sous forme de tableau, sous forme de document JSON, etc...

  11. #11
    Expert confirmé
    Homme Profil pro
    Développeur .NET
    Inscrit en
    novembre 2009
    Messages
    1 917
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : novembre 2009
    Messages : 1 917
    Points : 5 221
    Points
    5 221
    Par défaut
    Citation Envoyé par Anselme45 Voir le message
    Je ne confonds rien par contre je peux te dire que ton commentaire démontre que tu ne connais pas ce que tu te proposes de commenter. On ne peut pas tout connaître mais il est toujours utile de rester humble quand on pose des questions dans un domaine où l'on n'excelle pas. Cela évite de passer pour un "coui...on".
    Effectivement, quand on pose une question, c'est qu'on ne connait pas.
    En revanche ta réponse avec les drivers, qui n'a absolument ni de près ni de loin, un quelconque rapport avec les avantages spécifiques de REST, ne laisse pas supposer que tu maitrises le sujet, tout en utilisant le produit. Perso ça me fait peur.
    Je te signales, qu'en tant qu'utilisateur, tu n'as toujours pas était capable de répondre à ma question de l'intérêt de REST, à la place de l'utilisation d'un simple POST. Je ne prétends pas qu'il n'y a pas d'avantage, je pose la question pour qu'un expert puisse me répondre...S'il n'y en a pas (d'expert, ou d'avantage) c'est pas bien grave!

  12. #12
    Expert confirmé
    Homme Profil pro
    Développeur .NET
    Inscrit en
    novembre 2009
    Messages
    1 917
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : novembre 2009
    Messages : 1 917
    Points : 5 221
    Points
    5 221
    Par défaut
    Citation Envoyé par ji_louis Voir le message
    En utilisant une procédure stockée que le DBA (responsable de la base de données) aura calibré
    Merci pour la réponse,
    Mais est-ce une solution, ou c'est LA solution ?
    Là au final si je comprends bien ta proposition, tu vas devoir faire des procédures stockées "métiers" dont certaine vont par exemple être à base de jointure.
    Mais alors à quoi sert le système de requêtage que propose PostgREST ? De faire des joins sur les résultats des procédures stockées (me semble peu performant)?

    Par ailleurs, je n'ai rien contre les procédures stockés, c'était extrêmement à la mode il y a 20 ans, beaucoup moins (voire totalement ringard) ces dernières années, est-ce que ce PostgRest est une proposition pour faire revenir sur le devant de la scène les "procstock" ?

  13. #13
    Membre extrêmement actif
    Homme Profil pro
    Développeur informatique
    Inscrit en
    octobre 2017
    Messages
    1 398
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : octobre 2017
    Messages : 1 398
    Points : 4 693
    Points
    4 693
    Par défaut
    Citation Envoyé par micka132 Voir le message
    Par ailleurs, je n'ai rien contre les procédures stockés, c'était extrêmement à la mode il y a 20 ans, beaucoup moins (voire totalement ringard) ces dernières années, est-ce que ce PostgRest est une proposition pour faire revenir sur le devant de la scène les "procstock" ?
    Tu as raison micka132, aujourd'hui la mode est au cloud piratable qui permet de vendre les données volées sur le darknet grâce à l'usage de technologies à la mode que personne n'a pris la peine de fiabiliser...

    Mais pourquoi donc faudrait-il revenir en arrière avec des technologies bien plus sûres?

  14. #14
    Membre extrêmement actif
    Homme Profil pro
    Développeur informatique
    Inscrit en
    octobre 2017
    Messages
    1 398
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : octobre 2017
    Messages : 1 398
    Points : 4 693
    Points
    4 693
    Par défaut
    Citation Envoyé par micka132 Voir le message
    Effectivement, quand on pose une question, c'est qu'on ne connait pas.
    En revanche ta réponse avec les drivers, qui n'a absolument ni de près ni de loin, un quelconque rapport avec les avantages spécifiques de REST, ne laisse pas supposer que tu maitrises le sujet, tout en utilisant le produit.!
    Est-ce que tu as déjà développé une application "client-serveur" dans ta vie? A la lecture de tes commentaires hautains, j'en doute!

    Si c'était le cas, tu aurais connaissance des différentes méthodes et architectures utilisées pour le faire...

    Mais, je ne vais pas ergoter plus longtemps, le ton condescendant que tu prends dans tes commentaires ne donne pas envie de converser avec toi.

Discussions similaires

  1. Réponses: 16
    Dernier message: 27/01/2020, 22h05
  2. Réponses: 0
    Dernier message: 28/08/2018, 13h57
  3. Réponses: 2
    Dernier message: 01/08/2017, 16h08
  4. Erreur sur Web service qui retourne une String
    Par Delphi-ne dans le forum WinDev
    Réponses: 9
    Dernier message: 26/05/2016, 13h39
  5. web service qui affiche une table depuis la BDD
    Par leilusha dans le forum NetBeans
    Réponses: 5
    Dernier message: 03/11/2015, 11h16

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo