À propos du projet
PostgREST est un serveur autonome qui expose une API entièrement RESTful au-dessus d'une base de données PostgreSQL existante. Selon son fichier README, il vise à fournir une API plus propre, plus conforme aux normes et plus rapide qu'une API généralement écrite à partir de zéro.
**Installation et utilisation**
La documentation couvre l'installation de PostgREST sur diverses plates-formes, et une image Docker est également proposée. Après l'installation, le point d'entrée en ligne de commande est appelé via `postgrest --help`. Le projet conserve sa documentation sur postgrest.org, les sources de la documentation étant stockées dans le dépôt afin que les contributeurs puissent soumettre des modifications.
**Architecture et performances**
Le README explique que le serveur est écrit en Haskell et utilise le serveur HTTP Warp, qu'il décrit comme un langage compilé avec des threads légers. Il délègue également autant de calculs que possible à la base de données, y compris la sérialisation des réponses JSON directement en SQL, la validation des données, l'autorisation, le comptage et la récupération combinés des lignes, ainsi que l'envoi de données en une seule commande via `returning *`. L'accès à la base de données utilise la bibliothèque Hasql, qui maintient un pool de connexions, utilise le protocole binaire de PostgreSQL et reste sans état pour permettre un passage à l'échelle horizontal. Le README indique un objectif de temps de réponse inférieur à la seconde pour jusqu'à 2000 requêtes par seconde sur une offre gratuite Heroku, présenté comme une affirmation de performance par le projet plutôt que comme un benchmark indépendant.
**Modèle de sécurité**
L'authentification est gérée via des jetons JSON Web Tokens, tandis que l'autorisation est déléguée aux informations de rôle définies dans la base de données. Le README présente cela comme une source unique et déclarative de vérité pour la sécurité : le serveur prend l'identité de l'utilisateur actuellement authentifié et, pendant la connexion, ne peut rien faire que cet utilisateur ne pourrait faire lui-même. Il note que d'autres schémas d'authentification peuvent être superposés au-dessus de la primitive JWT.
**Versionnement**
Le versionnement de l'API s'effectue via les schémas de la base de données, ce que le README présente comme un moyen d'exposer des tables et des vues sans rendre les applications fragiles. Les tables sous-jacentes peuvent être remplacées et masquées derrière des vues accessibles au public.
**Auto-documentation**
PostgREST utilise la norme OpenAPI pour générer une documentation d'API à jour, qui peut être rendue avec des outils tels que Swagger-UI pour des requêtes interactives sur un serveur en direct. Le README note également que des métadonnées supplémentaires circulent sur HTTP, par exemple le nombre de lignes renvoyées par un point de terminaison étant signalé et limité via des en-têtes de plage.
**Intégrité des données**
Au lieu de s'appuyer sur un mapper objet-relationnel et du code impératif personnalisé, le système s'attend à ce que des contraintes déclaratives soient placées directement dans la base de données, de sorte qu'aucune application — y compris le serveur API — ne puisse corrompre les données. Il expose une interface HTTP avec des garanties telles que l'application de requêtes PUT idempotentes, et le README renvoie à des exemples de contraintes PostgreSQL et au guide de l'API pour plus de détails.
**Projet et communauté**
Le développement est soutenu par des dons Patreon, et le dépôt répertorie les sponsors et soutiens. Les contributions sont les bienvenues conformément aux directives de contribution, et le README crédite les contributeurs ainsi que le concepteur du logo du projet.
Comments
0 Rating appears after 10 ratings
Sign in to join the discussion.