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

Vous �tes nouveau sur Developpez.com ? Cr�ez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et �tre connect� pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Cr�ez-en un en quelques instants, c'est enti�rement gratuit !

Si vous disposez d�j� d'un compte et qu'il est bien activ�, connectez-vous � l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oubli� ?
Cr�er un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

PostgREST : un serveur Web autonome qui transforme une base de donn�es PostgreSQL
Directement en une API RESTful

Le , par Bill Fassinou

570PARTAGES

18  0 
PostgREST : un serveur Web autonome qui transforme une base de donn�es PostgreSQL
directement en une API RESTful

PostgREST est un serveur Web autonome qui transforme votre base de donn�es PostgreSQL directement en une API RESTful. Les contraintes structurelles et les autorisations dans la base de donn�es d�terminent les points de terminaison et les op�rations de l'API. Sa version 6.0.2 a �t� publi�e en ao�t dernier avec de nouveaux ajouts et quelques modifications. PostgREST permet d'exposer une base de donn�es PostgreSQL sous forme d'API REST directement consommables par des applications mobiles, des portails Web ou bien des partenaires.

PostgREST sert une API enti�rement RESTful � partir de tout type de base de donn�es PostgreSQL existante. Selon l��quipe de d�veloppement, PostgREST fournit une API plus propre, plus conforme aux normes et plus rapide que celle que vous �tes susceptible d'�crire � partir de z�ro. Elle estime que son utilisation est une alternative � la programmation manuelle CRUD. PostgREST est un middleware open source et les API expos�es par PostgREST sont conforme � la sp�cification OpenAPI (anciennement connue sous le nom de sp�cification Swagger).

Selon sa documentation, il g�re nativement les d�pendances entre les tables de votre base de donn�es, ce qui vous permet au travers d'une simple requ�te REST de r�cup�rer des donn�es provenant d'une jointure entre deux tables. PostgREST serait tr�s rapide avec un temps de r�ponse inf�rieur � la seconde pour jusqu'� 2000 demandes/seconde sur le niveau gratuit Heroku. � Si vous �tes habitu� aux serveurs �crits dans des langages interpr�t�s, pr�parez-vous � �tre agr�ablement surpris par les performances de PostgREST �, explique l��quipe.

Trois facteurs contribuent cette vitesse selon l��quipe. Tout d'abord, le serveur est �crit en Haskell � l'aide du serveur HTTP Warp (un langage compil� avec des threads l�gers). Ensuite, il d�l�gue autant de calculs que possible � la base de donn�es, y compris la s�rialisation des r�ponses JSON directement dans SQL, la validation des donn�es, etc. Enfin, il utilise la biblioth�que Hasql pour garder un pool de connexions � la base de donn�es, le protocole binaire PostgreSQL et reste sans �tat pour permettre une mise � l'�chelle horizontale.


PostgREST g�re l'authentification (via JSON Web Tokens) et d�l�gue l'autorisation aux informations de r�le d�finies dans la base de donn�es. Cela garantit qu'il n'y a qu'une seule source d�clarative de v�rit� pour la s�curit�. En traitant avec la base de donn�es, le serveur assume l'identit� de l'utilisateur actuellement authentifi�, et pour la dur�e de la connexion ne peut rien faire que l'utilisateur lui-m�me ne pourrait pas faire. D'autres formes d'authentification peuvent �tre construites sur la primitive JWT. Vous pouvez obtenir plus d'informations dans la documentation.

Lorsqu�il s�agit de l�int�grit� des donn�es, plut�t que de s�appuyer sur un ORM (Object Relational Mapper) et sur un codage imp�ratif personnalis�, ce syst�me impose de mettre des contraintes d�claratives directement dans votre base de donn�es. Par cons�quent, aucune application ne peut corrompre vos donn�es (y compris votre serveur API). PostgREST expose l'interface HTTP avec des sauvegardes pour �viter les surprises, notamment l'application de requ�tes PUT idempotentes. Autrement dit, il n'y a pas d'ORM impliqu�.

La cr�ation de nouvelles vues se produit en SQL avec des implications connues en mati�re de performances. Un administrateur de base de donn�es peut d�sormais cr�er une API � partir de rien, sans programmation personnalis�e. Pour certains, PostgREST est �galement une alternative int�ressante � une base de donn�es NoSQL ou GraphQL nativement expos�e en API si vous avez besoin de garder un mod�le relationnel. Ils trouvent dommage que ce middleware ne soit pas disponible en standard dans les d�p�ts de package des grandes distributions Linux.

Sources : PostgREST, GitHub

Et vous ?

Qu'en pensez-vous ?

Voir aussi

Microsoft fait l'acquisition de Citus Data l'extension qui transforme PostgreSQL en une base de donn�es distribu�e

PostgreSQL 12 est disponible et apporte des am�liorations sur la performance des requ�tes, cette version introduit les � colonnes calcul�es � et supporte les colonnes g�n�r�es stock�es

Depuis 20 ans, PostgreSQL aurait mal utilis� fsync(), compromettant la coh�rence des donn�es, des solutions ont �t� propos�es au FOSDEM 2019
Vous avez lu gratuitement 0 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer � vous proposer des publications.

Une erreur dans cette actualit� ? Signalez-nous-la !

Avatar de grograg
Membre � l'essai https://www.developpez.com
Le 15/11/2019 � 16:15
PostgREST est un produit que j'ai mis en place chez mon ancien employeur, il est en production depuis 1-2 ans en tant que fournisseur de services sur des r�f�rentiels de donn�es.
Cela fonctionne super bien et �vite d'avoir � d�velopper un couche web d'acc�s aux donn�es.
Je ne l'ai mis en place que pour de la restitution de donn�es, je ne sais pas ce que vaut la partie MAJ de donn�es.

Par contre, je n'ai expos� que des vues (en l'occurrence mat�rialis�es) pour faciliter la maintenance. En effet, si l'on expose des tables avec PostgREST, en cas de modification de structure, il est n�cessaire de modifier tous les consommateurs (les services sont auto-g�n�r�s � partir des tables). En passant par des vues, il est possible de modifier la requ�te de la vue pour ne pas impacter les clients. Au pire, si la modification de structure n�cessite de changer la vue pour b�n�ficier de toutes les nouvelles donn�es, il est possible de cr�er une deuxi�me vue (marqu�e V2) et garder l'ancienne vue (avec requ�te mise � jour) pour les logiciels utilisant l'ancienne structure.

Le gros avantage de PostgREST, c'est que le consommateur fait un pseudo-SQL lorsqu'il utilise le service web. Pas besoin de d�velopper des services sp�cifiques lorsqu'il est n�cessaire de retourner des jeux de donn�es complexes, le d�veloppeur de l'application consommatrice est libre de faire � peu pr�s ce qu'il veut.

PostgREST est en Haskell, pas en Java.
3  0 
Avatar de Malick
Community Manager https://www.developpez.com
Le 17/12/2019 � 13:43
Salut,

Pour info, un tutoriel : PostgREST, mettre en place une API RestFull depuis n'importe quelle base de donn�es PostgreSQL


Bonne lecture
3  0 
Avatar de Anselme45
Membre extr�mement actif https://www.developpez.com
Le 06/11/2019 � 11:17
Citation Envoy� par cecedu26 Voir le message
On utilise deja ceci sur Oracle, c'est tres pratique et ca permet d'eviter a coder pas mal de code bete type CRUD sans aucune valeur ajout�e cote WS/API (C# dans notre cas).
Ca fait toujours une couche de moins a coder dans nos API REST et bonne alternative pour mettre a dispo des services en 0-dev.

A tester donc sur PostGreSql.

Question de n�ophyte:

N'y-a-t-il pas un risque plus �lev� de piratage en suppriment une couche REST et en connectant directement la base de donn�es au r�seau?

Merci pour vos r�ponses d'experts
2  0 
Avatar de SQLpro
R�dacteur https://www.developpez.com
Le 19/11/2019 � 10:16
�a existe sous SQL Server depuis la version 2005 via les web services.

Cependant pour des raisons de s�curit� cela est strictement d�conseill� !

En effet, le point noir de la probl�matique est que d�s lors que c'est le moteur qui fait les requ�tes et non plus l'utilisateur qui a la mainmise dessus, il n'est plus possible d'appliquer une, s�curit� aussi fine que celle qui est possible en SQL (privil�ges).

Cela a �t� la m�me chose pour Oracle....

A +
1  0 
Avatar de fbenoist68
Candidat au Club https://www.developpez.com
Le 18/01/2020 � 16:28
Bonjour,

Je suis �tonn� de la relative "simplicit�" de postgREST et que beaucoup s'en accommode (� priori).
Je g�re actuellement une application "moyenne" (FrontEnd HTML/AJAX + Middleware sous Oracle Glassfish) / et 99% du code des web services REST est �crit en PL/SQL ORACLE (plut�t orient� RPC donc) . Je souhaite r�-�crire cette application mais changer d'architecture BDD pour PostgreSQL. Un FrontEnd en node.js + suite "vue.js" et un backend en ... :
- Django DRF mais il faut constamment contourner le fonctionnement de base et c'est un peu lourd pour une application moyenne
- Peut �tre FASTAPI + SQLAlchemy (donc en python et en mode ORM)
- je viens de tomber sur PostgREST ...
Pour reprendre les avis d�j� �cris je me demande qu'elle type d'application moderne peut se contenter de simples appels CRUD mono-table en update/delete ...?? Lorsque j'update un enregistrement, outre des v�rifications last minute des param�tres, je mets � jour une table de logs (utilisateur, param�tre d'appels, temps d'execution du ws service ...), et suivants les cas je met bien souvent � jour d'autres tables (qui plus est dans une transaction - obligatoirement - ...)
Lors d'un delete dans une table, il n'est pas rare de devoir supprimer logiquement ou mettre � jour des enregistrement dans une autre. Evidemment on peut faire certaines de ces actions via des triggers mais le debugage risque d'�tre long et d�licat.
Si je devais choisir PostgREST ce n'est pas pour repasser sur des proc�dures stock�es (RPC) quasiment tout le temps.
Outre la vitesse, j'ai du mal � croire que PostgREST puisse convenir pour g�rer 100% des acc�s data (autres qu'en lecture) d'un petit back-office.
1  0 
Avatar de cecedu26
Membre r�gulier https://www.developpez.com
Le 05/11/2019 � 21:22
On utilise deja ceci sur Oracle, c'est tres pratique et ca permet d'eviter a coder pas mal de code bete type CRUD sans aucune valeur ajout�e cote WS/API (C# dans notre cas).
Ca fait toujours une couche de moins a coder dans nos API REST et bonne alternative pour mettre a dispo des services en 0-dev.

A tester donc sur PostGreSql.
0  0 
Avatar de walfrat
Membre �m�rite https://www.developpez.com
Le 06/11/2019 � 9:04
C'est d�finitivement int�ressant, cependant j'ai toujours eu des difficult�s � exprimer certain types de contraintes.

Par exemple avec CHECK on ne peut faire de requ�te pour v�rifier une condition complexe. De fait j'ai donc souvent une premi�re couche d'int�grit� en BDD et une autre c�t� applicatif.

Une autre possibilit� serait donc � mapper une URL vers une proc�dure stock�e plut�t que la table en elle-m�me qui peut effectuer les contr�les compl�mentaires.

Enfin l'authentification est souvent plut�t c�t� applicatif de nos jours, ne serait-ce que pour faire des pools de connexions. D'apr�s ce que dit cet article, je ne sais pas si l'authentification propos� fonctionne comme une authentification applicative ou s'il faut passer par la gestion des utilisateurs et r�les de la base, ce dernier serait g�nant sur le type d'application que je d�veloppe et la complexit� de la gestion des droits qui en r�sulte.
0  0 
Avatar de Madmac
Membre extr�mement actif https://www.developpez.com
Le 06/11/2019 � 23:48
Citation Envoy� par Anselme45 Voir le message
Question de n�ophyte:

N'y-a-t-il pas un risque plus �lev� de piratage en suppriment une couche REST et en connectant directement la base de donn�es au r�seau?

Merci pour vos r�ponses d'experts
Il y a probablement un protocole pour authentifier les requ�tes. Je n'utiliserais pas ce truc pour faire des entr�es, mais pour des sorties uniquement. mais pour une application personnelle, �a pourrait-�tre utile pour quelqu'un qui ne connais aucun truc comme Rails.

Mais ce que j'en d�duis, c'est que PostgreSQL pourrait �tre aussi simple � utiliser que MySQL.

� suivre ...
0  0 
Avatar de mohamedimli
Candidat au Club https://www.developpez.com
Le 07/11/2019 � 8:03
Le fait que cette api REST est conforme au standard OpenApi est une bonne chose ! Cela veut dire que nous pouvons g�n�rer un client d'acc�s aux donn�es AUTOMATIQUEMENT et GRATUITEMENT pour n'importe quel langage suportant HTTP !

Sauf que je me pose la question : est ce que cela revient moins cher de maintenir et payer un serveur de plus que de payer pour l'�crire manuellement avec jdbc par exemple ?
0  0 
Avatar de cecedu26
Membre r�gulier https://www.developpez.com
Le 07/11/2019 � 11:11
Citation Envoy� par Anselme45 Voir le message
Question de n�ophyte:

N'y-a-t-il pas un risque plus �lev� de piratage en suppriment une couche REST et en connectant directement la base de donn�es au r�seau?

Merci pour vos r�ponses d'experts
Non, puisque la couche est "supprim�e" en terme de codage de notre cot� (donc 0-dev) mais elle reste bien malgr� tout presente. Il faut bien que quelqu'un fasse l'interface avec la BDD. Je prefere une mecanique int�gr�e et g�r�e par le fournisseur que de devoir recoder de la securit� de notre cot� (ou il y a plus de chances de laisser passer des choses).

Ce qui est interessant c'est qu'en plus on a de base la portabilit� multi plateforme (la ou on devrait coder une couche en C# pour telle ou telle plateforme dans un mode classique), l� c'est la BDD deja multiplateforme qui fait le job (visiblement c'est une appli java qui fait l'interface donc portabilit� de fait). Donc gagnant sur toute la ligne.
0  0