Forum : [Angular] Généralités appel HTTP

Bonjour,

Avec un ami, nous commencons à utiliser Angular et Spring.
Nous avons quelques questions auquels nous ne trouvons pas de réponse claire sur internet.

Pour s'entrainer, nous aimerions faire une page qui affiche un article et des commentaires de la part des utilisateurs au sujet de cet article. Un sujet assez habituelle il me semble :)

1/ Faut-il faire un appel HTTP pour recevoir le contenu de l'article et un autre pour recevoir les commentaires de cet article? Ou est-il préférable (performance, organisation du code, bonnes pratiques, ...) de faire un seul appel qui retournera le contenu de l'article ET les commentaire ?

J'ai cru comprendre qu'Angular fonctionne par "components" donc j'aurais tendance à faire deux composants, même deux services (un pour les articles et l'autre pour les commentaires) et au final deux appels HTTP. Cependant, j'imagine qu'un appel permettant de recevoir toutes les informations de la page serait plus perfomants/rapide que deux appels différents.

2/
Lors du POST HTTP pour créer un nouveau commentaire, nous avons besoin d'envoyer au back l'id de l'utilisateur qui souhaite enregistrer ce commentaire. Est-il preferable d'envoyer un champ number "id_user" ou un object "User"? (Exemple ci-dessous)

La premiere solution permettrait d'envoyer moins d'informations inutile car au final seul l'ID de l'utilisateur est utile mais apparement Spring utilise des "entitées" et il semble plus simple coté Spring de recevoir un object "User" dans le back plutot que de faire le lien manuellement entre le number "id_user" et l'objet "User".

Exemple:

{
  "id": 0,
  "content": "blabla",
  "creator_id": 2
}

{
  "id": 0,
  "content":
  "blabla",
  "createdBy": {
    "id": 2,
    "username": "toto",
    etc...
  }
}

En esperant ne pas avoir dit trop de bétises.
Merci pour votre attention :)

2 réponses

Maenhyr

Bonjour,

1) je dirais que c'est un choix. Personnellement je ferais 2 endpoints (/posts/1 et /posts/1/comments). Cela rendra le code un peu plus flexible (par exemple, lorsque tu veux afficher une liste de posts, tu n'as pas besoin des commentaires donc autant éviter de les envoyer. Sur mobile, tu peux avoir la liste des commentaires sur une vue spécifique, donc pas besoin du post, ...).

2) Si un utilisateur ne peut écrire un commentaire que lorsqu'il est connecté, alors tu n'as pas besoin d'envoyer le user ou l'id dans ton POST. Tu seras capable de retrouver ces informations dans ton BE grâce au token (au autre information suivant ton système d'authentification).

etorion

Bonjour,

1) Tout à fait d'accord avec ce qui a dit prbaraon.
Tout dépendra du volume à réceptionner. Si c'est pour s'entrainer ou faire une démo, un seul appel suffira. Si c'est pour faire un vrai site, deux appels seraient biens. Pour aller plus loin, les deux appels je les filtrerai avec un appel odata, afin de limiter le volume retourné. Il faut penser mobile avant tout. On affiche un nombre d'articles et on donne soit un apperçu des commentaires, soit un boutton qui permet de les consulter.

2) Le token devrait suffire, mais rien ne t'empèche de renvoyer un id, renvoyer une entitée est un peu lourd. Je ne connais pas Spring, vu que je code en C# et je n'inutilise pas ce genre d'outil.
Pour moi ce qui compte ce n'est pas le back end, c'est la Base de données. Quelle est la longueur du commentaire que tu veux stocker et que tu peux stocker? c'est la seule question à mon sens.