API

Le module n'expose aucune fonction serveur sous son propre nom de package. Tout ce qu'un consommateur peut appeler passe par les façades @lrvo/core/media-registry, que le module remplit au boot.

Règle absolue : depuis un Server Component, un bloc ou un module, ne jamais appeler les routes HTTP avec fetch. Ce sont des routes d'admin, elles exigent une session. Importer les façades du core, qui couvrent le même périmètre, téléversement compris.

Import

Ce sont les deux seuls points d'entrée. Le CRUD, le pipeline d'optimisation et les aides du BlockEditor ne sont pas exposés, et un import profond dans dist/ n'est pas une voie supportée.

// Depuis un module consommateur, toujours ceci :
import { getMediaById, buildMediaUrl, attachMedia } from '@lrvo/core/media-registry';

API

Les fonctions utilisables depuis du code sont documentées dans Registre média, et leur usage dans Intégration.

Toutes restent appelables sans le module et se comportent alors de façon neutre.

Le CRUD est publié dans le registre : un module, une server action ou une tâche planifiée déposent un fichier sans session d'admin, avec uploadMedia. L'auteur y est optionnel. Voir Registre média.

Routes HTTP

Admin

Toutes sont montées sous le préfixe /lrvo/api, comme le veut core/api, et exigent une session d'administration en plus de leur permission.

GET /media accepte page, limit (24 par défaut, 100 au maximum), search sur le nom d'origine, et kind parmi image, video, audio, document et other. Le tri est fixe, du plus récent au plus ancien.

Le filtre kind=other ne produit aucune condition et renvoie donc la liste complète, alors que l'interface propose l'option.

POST /media attend un champ file, plus éventuellement altText et caption. Voir Téléversement pour les formats et les limites.

POST /media/bulk-download attend { ids }, cent au plus, et renvoie une archive assemblée à la volée, sans recompression. Les objets absents du stockage sont sautés sans faire échouer l'archive.

DELETE /media/:id échoue en 400 si le média est encore référencé, avec le nombre de contenus concernés dans le message. Détacher d'abord. Voir Intégration.

Publique

Ce n'est pas une route du routeur d'API : c'est un Route Handler Next.js monté par le projet, hors du préfixe /lrvo/api. Voir Installation.

Elle retrouve la fiche par son nom public, lit l'objet au stockage et diffuse le flux. Elle répond 404 si le nom est inconnu ou si l'objet est absent du stockage, 400 si le nom est mal encodé.

Les en-têtes appliqués sont détaillés dans Téléversement. Le point à retenir : seuls JPEG, PNG, GIF et WebP sont servis en affichage direct, tout le reste est forcé en téléchargement.

Notes

• Un nom de fichier déjà pris fait échouer le PATCH, sans qu'aucun champ ne soit écrit. Le handler renvoie bien le code Conflict et son message, mais getStatusCode du core ne connaît pas ce code et retombe sur 500 au lieu du 409 attendu par l'interface. Un client qui teste le statut doit donc lire le champ error du corps.
• Aucune route d'API publique n'existe. Un consommateur externe ne peut ni lister ni interroger la médiathèque, il ne peut que lire un fichier dont il connaît le nom.
• Les routes ne sont enregistrées que lorsque le module est activé. Désactivé, le préfixe /media ne répond pas.