PostgREST : exposez votre base PostgreSQL en REST

1. 1. Une API REST directement depuis votre base de données
2. 2. Une logique déclarative basée sur le SQL
3. 3. Gagner du temps sur les projets data-driven
4. 4. Contrôle, permissions et sécurité
5. 5. Quand utiliser PostgREST (et quand éviter)
6. Repenser l’API autour de vos données

1. Une API REST directement depuis votre base de données

Créer une API implique souvent de bâtir toute une couche applicative autour de la base de données. Routes, contrôleurs, règles métiers, logique de transformation… tout s’ajoute pour exposer des données qui, dans bien des cas, sont déjà prêtes à l’usage. PostgREST prend le contre-pied de cette approche. Plutôt que de construire autour, il propose d’exposer directement la base comme une API RESTful structurée, fiable et entièrement pilotée par le schéma PostgreSQL.

La mise en route est rapide. Une fois configuré, le service expose automatiquement les tables comme des points d’accès REST. Les vues peuvent servir de filtres ou de regroupements, et les relations deviennent des chemins que l’on peut explorer depuis l’API. Les actions habituelles comme la lecture, la création, la modification ou la suppression sont accessibles via des requêtes HTTP standard, sans ajout de logique côté serveur.

Cette manière de faire inverse la logique traditionnelle du développement. Au lieu de reproduire la structure des données à travers des routes ou des contrôleurs, on s’appuie directement sur le modèle existant. La base devient l’interface. Ce raccourci réduit la charge de travail, limite les écarts entre le stockage et l’exposition des données, et simplifie l’ensemble du projet.

2. Une logique déclarative basée sur le SQL

La logique de PostgREST repose entièrement sur la structure existante de la base de données. Ce ne sont pas des fichiers de configuration ou des lignes de code applicatif qui dictent le fonctionnement de l’API, mais les objets SQL eux-mêmes. Tables, vues, fonctions et rôles définissent directement ce qui est exposé, comment c’est accessible, et dans quelles conditions.

Tout repose ici sur une logique déclarative. Il ne s’agit pas de coder les points d’entrée manuellement mais de les rendre accessibles en structurant correctement la base. Lorsqu’une vue est créée, elle devient instantanément exploitable en tant que ressource. Une fonction bien définie peut être exposée comme une opération distante, sans configuration supplémentaire. Quant aux rôles utilisateurs, ce sont eux qui fixent précisément les droits d’accès. PostgREST s’appuie directement sur ces règles pour déterminer ce qui peut être consulté ou modifié par chaque profil.

Ce modèle oblige à penser la base de données comme un composant central et non plus comme un simple espace de stockage. Et pour les projets fortement structurés autour de la donnée, ce changement de perspective peut apporter beaucoup de clarté, de contrôle et de stabilité sur le long terme.

3. Gagner du temps sur les projets data-driven

Il arrive que la logique d’un projet soit déjà largement portée par la base de données. Les relations sont claires, les règles sont définies en SQL, et le schéma reflète fidèlement les besoins métier. Dans ce genre de configuration, ajouter une couche applicative devient souvent superflu. PostgREST s’inscrit parfaitement dans cette approche en exposant l’existant de manière structurée, sans réinventer ce qui fonctionne déjà.

En exposant directement les tables et les vues comme ressources REST, on évite de devoir réécrire ce qui existe déjà dans la base. Pas besoin de définir manuellement des routes, de mapper des modèles ou de coder des contrôleurs. On se concentre sur l’essentiel : concevoir une base solide et exprimer la logique métier en SQL, là où elle est la plus lisible et la plus performante.

Ce fonctionnement permet de livrer rapidement une API fonctionnelle, alignée sur les règles métier et prête à être consommée. C’est un vrai gain de temps, mais aussi une façon de garder une cohérence forte entre le schéma de données et les usages réels de l’API.

4. Contrôle, permissions et sécurité

L’idée d’exposer directement une base de données via une API peut sembler risquée au premier abord. Pourtant, c’est justement l’un des points forts de PostgREST : s’appuyer sur les mécanismes de sécurité natifs de PostgreSQL pour contrôler précisément qui peut accéder à quoi, et dans quelles conditions.

Les droits d’accès sont gérés via les rôles et les vues. On peut définir finement les opérations autorisées en lecture ou en écriture, limiter les colonnes exposées, restreindre l’accès à certaines lignes en fonction du contexte, ou encore encapsuler des opérations sensibles dans des fonctions SQL spécifiques. Rien ne sort de la base sans avoir été validé par une règle explicite.

Ce fonctionnement replace la logique de sécurité là où elle a le plus de sens dans le cadre du projet. Toutes les règles sont définies directement dans le schéma, ce qui évite les doublons entre plusieurs couches techniques. L’ensemble reste cohérent, solide et fidèle aux contraintes métier sans dépendre d’une implémentation séparée ou dispersée.

5. Quand utiliser PostgREST (et quand éviter)

PostgREST brille dans les projets centrés sur la donnée, où le schéma SQL est solide, bien pensé et stable. Il permet de créer une API rapidement, sans écrire de backend, tout en gardant un contrôle précis sur la structure et les accès. C’est un outil idéal pour les backoffices, les dashboards internes, les prototypes avancés ou même certaines applications en production, si la logique métier reste proche de la base.

Mais cette approche ne convient pas à tous les contextes. Dans les projets où les règles métier sont complexes, réparties sur plusieurs services ou très évolutives, PostgREST peut montrer ses limites. L’absence de couche applicative rend certaines logiques difficiles à exprimer, surtout quand elles dépendent de contextes utilisateurs variés ou d’états intermédiaires.

Il faut aussi accepter de penser l’architecture différemment. PostgREST n’est pas là pour remplacer un framework web classique, mais pour proposer une autre façon de faire, plus directe, plus cohérente avec la base. Et dans les bons cas d’usage, cette approche peut apporter un vrai gain de temps, de clarté et de maintenabilité.