Comment rester RESTful sans sacrifier la perf côté front?

[Kevin14]

Salut tout le monde. Je suis un peu dans le flou sur un truc de conception d’API, et je me demandais si certains d’entre vous avaient déjà eu ce sentiment. Je bosse sur un petit projet perso, et j’ai passé un temps fou à structurer mes endpoints pour qu’ils soient vraiment RESTful, en suivant toutes les bonnes pratiques à la lettre. Mais là, en écrivant la doc pour le front-end, je me rends compte que pour un cas d’usage bien précis, le client doit faire trois appels séquentiels juste pour afficher une seule page, ce qui semble vraiment lourd et pas optimal pour l’expérience utilisateur. Du coup, je me demande si j’ai poussé le principe trop loin, et si dans ce genre de situation, il vaut mieux sacrifier un peu de “pureté” REST pour une performance plus concrète. J’ai l’impression d’avoir un peu trop idéalisé l’architecture au détriment du côté pratique.

[Edward.L]

Je comprends ce dilemme REST c'est utile mais l'expérience utilisateur passe avant tout. Trois appels pour une seule page c'est lourd et souvent utile d'envisager des endpoints qui regroupent les données ou des mécanismes d'expansion via des paramètres. Tu peux aussi penser à un petit cache du front ou à un appel parallèle orchestré par le front pour gagner du temps.

[Paisley_J]

Le problème rappelle le vieux débat entre pureté REST et performance réelle. Le compromis peut tenir par des patterns comme des endpoints riches mais équilibrés ou par un backend pour frontend BFF qui expose des réponses adaptées à la page sans briser REST. On peut aussi envisager des chargements parallèles ou des données en cache à la demande via un header de versionnement.

[Daniel.M]

Franchement REST c est souvent une belle idée sur le papier mais sur le terrain les contraintes réseau font la loi. Trois appels pour une page c est pas dramatique si le front peut les faire en parallèle et si la réponse est bien chunkable. Je me méfie des dogmes quand l'utilisateur ne voit pas la différence.

[Ethan68]

Ce que tu poses c est une tension entre pureté REST et l impression de lenteur de l interface. On peut reformuler la question autour de comment on équilibre cohérence et rapidité sans trahir le modèle mental de l API REST.

[Jeffrey23]

Le lecteur attend une API REST qui parle aussi le langage de l expérience actuelle et pas seulement la théorie. Des mots comme performance et lisibilité changent les choix et le style de la doc REST ne signifie pas avoir tout en une fois.

[Stella_C]

Si tu veux garder REST et gagner en performance sans tout casser tu peux envisager un BFF ou des champs d expansion et un caching intelligent. Tu peux aussi documenter clairement ce qui peut être attendu et ce qui est en prefetch partout sur ta doc front end. L essentiel est de tester et de mesurer l impact sur le temps à l affichage et sur la complexité du front.