Des named pipes à l'échelle d'Internet
POST sur un path. GET sur le même path. Les données circulent direct de l'émetteur au récepteur — sans buffering, sans upload, sans stockage. Juste du HTTP.
Terminal A — Émetteur
$ curl -T report.pdf \
https://abc123-def456-pipe-1.node-us-1.containers.hoody.com/api/v1/pipe/report
[INFO] En attente d'un récepteur...
[INFO] Streaming vers 1 récepteur(s)...
[INFO] Transfert terminé.
Terminal B — Récepteur
$ curl https://abc123-def456-pipe-1.node-us-1.containers.hoody.com/api/v1/pipe/report \
-o report.pdf
% Total report.pdf
100 2.4M 100 2.4M 0 0 1.8M
Les données traversent, elles ne s'arrêtent pas
Chaque byte que vous envoyez arrive aux récepteurs en temps réel. Le serveur est un fil, pas un entrepôt.
SOURCE
émetteur
PIPE SERVER
aucun stockage · jusqu'à 256 récepteurs
SINK
récepteur
L'émetteur s'ouvre
L'émetteur fait POST ou PUT sur n'importe quel path. Le serveur attend — jusqu'à 5 minutes — qu'un récepteur se connecte.
Les bytes traversent
Les données streament byte par byte sur le fil. Aucun buffering. Aucun fichier temporaire. Aucune étape d'upload.
Les récepteurs se connectent
Les récepteurs font GET sur le même path et tirent le stream en direct. Jusqu'à 256 récepteurs peuvent fanout depuis un seul émetteur.
Compositions Pipe courantes
La plupart des recettes tiennent en deux commandes curl — une pour envoyer, une pour recevoir.
Ce qui peut traverser un Pipe
Tout Content-Type non exécutable comme script passe verbatim. Les MIME dangereux sont réécrits en text/plain — la donnée n'est pas perdue, le XSS est prévenu.
application/octet-streamPUT → GETFichiers binaires, archives, images
/api/v1/pipe/{path}text/plainPOST → GETLogs, stdin, config, streams stdout
/api/v1/pipe/{path}multipart/form-dataPOST → GETUpload de fichier navigateur (première partie seulement)
/api/v1/pipe/{path}video/webm, video/mp4PUT → navigateurPartage d'écran, vidéo enregistrée
/api/v1/pipe/{path}?videotext/event-stream (SSE)GET spectateurSuivi de progression, vitesse/ETA/état
/api/v1/pipe/{path}?progresstext/html (réécrit)PUT → GETRéécrit en text/plain avant forward — XSS prévenu, donnée préservée
/api/v1/pipe/{path}Headers personnalisésPUT → GETMétadonnées X-Hoody-Pipe, X-Piping forwardées
/api/v1/pipe/{path}Tous les endpoints vivent sur /api/v1/pipe/[path]. La direction décrit qui écrit, qui lit.
Conçu pour le volume
Limites strictes appliquées par serveur. HTTP 429 quand la capacité est pleine, HTTP 414 quand les paths sont trop longs.
256
Récepteurs max sur un seul path
1,000
Connexions en attente non établies
1,000
Streams simultanés en cours
5 min
TTL avant éviction HTTP 408
1,024
Longueur max d'un path en caractères
9 endpoints, deux commandes qui comptent
POST ou PUT pour envoyer. GET pour recevoir. Tout le reste, c'est de l'observabilité.
Observabilité & UI
6 endpointsGET /api/v1/pipe/health → 200 { status, service, built, started, memory, … }
Transfert de données
3 endpointsPOST ou PUT pour envoyer · GET pour recevoir
À deux commandes curl près
Pas de SDK. Pas de setup d'auth. Pas de limite de taille de fichier. Lancez un conteneur Pipe et commencez à transférer.