Comment équilibrer une api entre objets imbriqués et identifiants ?

[TimothyQM]

Salut à tous. Je suis un peu dans le flou sur un truc de conception d'API. J'ai toujours structuré mes réponses en imbriquant les objets liés, mais là je bosse avec une équipe frontend qui insiste pour que je renvoie tout à plat avec juste des IDs, en disant que c'est plus flexible pour eux. De mon côté, je trouve que ça va faire plein d'appels supplémentaires côté client pour récupérer les données. Je me demande si je ne devrais pas plutôt opter pour une approche hybride avec une option pour inclure les objets embeddables. Vous avez déjà eu ce genre de débat ?

[Aubrey.M]

J'ai déjà eu ce genre de débat. L'argument pour les IDs tout seuls est séduisant côté frontend, mais dès qu'il y a des objets liés on se retrouve à multiplier les appels. L'idée d'embeddables peut éviter le back and forth, mais elle crée du duplicata et des schémas plus lourds à faire évoluer. Tu vois ce que je veux dire par embeddables comme option hybride ?

[Emily_G]

Pour moi c'est un dilemme de balance. Embeddables offrent une meilleure expérience utilisateur sans appels supplémentaires, mais ça peut vite bloquer la lisibilité et le versioning. Il faut une règle claire sur quand embed et quand laisser les IDs. Tu as déjà tenté une liste de champs embeddables réutilisables ?

[Scarlett.T]

J opte souvent pour l hybride mais avec des règles claires, un endpoint qui renvoie les objets principaux et un paramètre include embeddables pour récupérer les objets liés quand c est nécessaire. Embeddables pour gagner du temps, mais attention à la taille des payloads.

[RobertLL]

Ça me paraît aussi une question de flux: les attentes des lecteurs frontend veulent beaucoup de flexibilité; écrire en flat avec des IDs peut sembler simple mais demande des calls supplémentaires. Un modèle pourrait être embeddables optionnels, versionné, avec des sous champs définis. Est ce que vous mesureriez l impact sur le cache et sur les invalidations ?

[Richard92]

Je préfère reformuler le problème: ce n est pas embed ou pas mais comment équilibrer performance, cohérence et evolutivité. Le mot embeddables apparaît comme un compromis, pas comme une solution magique; vous pourriez aussi penser à des views cote serveur qui exposent a la fois un payload plat et des references.

[Scott.T]

Franchement j ai vu des equipes qui restent sur des IDs et les dev frontend reclamant tout le temps embed this. Mon choix penche pour l hybride mais je garde les embeddables sous controle par une politique stricte de schéma et de versioning. Embeddables peuvent fonctionner si on les documente et on teste.