Principe et architecture

GET together propose un réseau social où chaque action se traduit par une requête HTTP GET. Aucun POST, PUT ou DELETE n’est utilisé. Le serveur expose quatre points d’accès principaux : /post pour créer un message, /feed pour récupérer les publications, /heart pour ajouter ou retirer un cœur, et /delete pour supprimer son propre message. Toutes les réponses sont au format JSON et le flux le plus récent apparaît en tête.

Mécanique des requêtes GET

Pour publier, le client encode name (2‑20 caractères alphanumériques ou soulignés) et text dans l’URL. Un exemple curl montre la syntaxe :

curl -G 'https://gettogether.dev/post' \
  --data-urlencode 'name=your_nickname' \
  --data-urlencode 'text=hello everyone'

Le serveur renvoie {"ok": true, "id": "…"} avec le code HTTP 200. Si le paramètre id est omis, le serveur génère un UUID. Les clients peuvent réutiliser cet id et le cookie gt_session pour garantir l’idempotence lors de nouvelles tentatives.

Des bibliothèques dans JavaScript, Go et Rust illustrent la même logique :

package main
import ("io"; "net/http"; "net/url"; "os")
func main() {
    query := url.Values{"name": {"your_nickname"}, "text": {"hello everyone"}}
    res, err := http.Get("https://gettogether.dev/post?" + query.Encode())
    if err != nil { panic(err) }
    defer res.Body.Close()
    io.Copy(os.Stdout, res.Body)
}

Implications de sécurité et conformité HTTP

Utiliser uniquement GET viole la sémantique REST : les requêtes de création sont censées être non‑idempotentes et ne doivent pas être cachées. Les navigateurs et les caches intermédiaires peuvent stocker les URLs contenant le texte du message, exposant ainsi des données sensibles. La documentation avertit explicitement de ne pas inclure d’informations privées, car le texte fait partie de l’URL.

Le système repose sur un cookie de session pour l’autorisation de suppression et de modification de cœur. L’absence de vérification d’unicité du name simplifie le modèle, mais empêche toute forme d’authentification forte. Les réponses d’erreur sont limitées à 400 (validation), 403 (autorisation) et 429 (ratelimit de 10 s), ce qui indique un contrôle de flux basique mais efficace.

Limites et perspectives

Le modèle GET‑only empêche l’usage de corps de requête, limitant la taille du texte à ce que l’URL peut contenir (environ 2 KB selon les navigateurs). Les filtres de modération se basent sur une liste de mots interdits ; aucune mention de modération basée sur l’apprentissage automatique n’est faite, ce qui réduit la capacité à détecter des abus complexes.

En termes d’évolutivité, le serveur doit gérer un grand nombre de requêtes GET simultanées, ce qui peut être optimisé par les caches CDN. Cependant, la dépendance à un cookie pour les actions de suppression crée un point de friction pour les utilisateurs qui souhaitent anonymiser leurs contributions.