Discussion :

[vallica]

Bonjour à tous,

Je développe actuellement une API REST qui est consommée d'une part par une application mobile et d'autre part part le backoffice de cette même app.

Je me demandais comment organiser ses endpoints lorsque les accès front et back on des besoins très différents, j'explique :

1 - Pour l'app je fais un endpoint mon.api.com/articles qui me renvoie la liste des articles que l'utilisateur courant a le droit de voir. Cet endpoint prend donc en paramètre l'user courant pour personnaliser la liste des articles retournée

2 - Coté backoffice je vais aussi avoir besoin d'accéder à cet endpoint mais avec d'autres besoins : pouvoir accéder à la liste des articles tous utilisateurs confondus, pouvoir trier, filtrer par statuts, etc.

Du coup comment faire ? un seul endpoint /articles commun au front et au back et qui détecte la présence de paramètres pour savoir comment se comporter, ou bien séparer en deux endpoints ?

J'imagine qu'il n'y a pas de réponse toute faite, mais je recherche une éventuelle bonne pratique.

Merci !

[headmax]

Salut en général les API : envoie une liste de collections, une collection, un élément de la collection dans la logique CRUD (create, read, update, delete).

mon.api.com/read/users/articles -> retourne la collection des articles pour tout utilisateurs (HTTP GET)

mon.api.com/read/user/articles -> retourne la collection articles de l'utilisateur (HTTP GET)
mon.api.com/read/user/article/12 -> retourne l'article id 12 de sa collection d'articles. (HTTP GET)
mon.api.com/create/user/article/12 -> crée l'article id 12 dans sa collection d'articles. (HTTP POST)
mon.api.com/update/user/article/12 -> met à jours l'article id 12 de sa collection d'articles. (HTTP PUT)
mon.api.com/delete/user/article/12 -> supprime l'article id 12 de sa collection d'articles. (HTTP DELETE)

mon.api.com/read/admin/articles -> retourne se que tu souhaite pour le côté back-office de l'API (HTTP GET)
mon.api.com/create/admin/articles -> créer un "bulk" articles (HTTP POST)
mon.api.com/delete/admin/articles -> supprime un "bulk" articles (HTTP DELETE)
mon.api.com/update/admin/articles -> met à jour un "bulk" articles (HTTP PUT)

mon.api.com/read/admin/article -> retourne l'article id 120 (HTTP GET)
mon.api.com/create/admin/article/120 -> crée un nouveau article id 120 (HTTP POST)
mon.api.com/delete/admin/article/120 -> supprime l'article id 120 (HTTP DELETE)
mon.api.com/update/admin/article/120 -> met à jour l'article id 120 (HTTP PUT)

[vallica]

Salut, donc si je comprends bien je cloisonne le front et le back avec le préfixe d'url /user ou /admin

Pas mal, merci, ça a le mérite d'être clair

(Si d'autres on un avis différent sur le sujet je reste preneur)

[headmax]

La logique des accès au URL a pour but la compréhension le plus simple possible pour les utilisateurs de l'API après la sémantique "create, delete, update ..." peut tout a fait être adapté selon le publique ciblé, si francophone dans ce cas là changé pour des url construites en Français voir plusieurs langages il faut de la flexibilité pour les "endpoints".

[vallica]

Compris, merci encore

[Spartacusply]

Salut,

Je développe actuellement une API REST qui est consommée d'une part par une application mobile et d'autre part part le backoffice de cette même app.

Ok mais en toute logique la back-office de l'appli est déjà une API elle aussi donc attention à ne pas s'emmêler les pinceaux et à ne pas complexifier inutilement en rajoutant une autre API. Attention si le back et l'API sont deux environnement bien distincts ou que si le back t'es imposé tout simplement cela peut tout à fait se justifier.

mon.api.com/read/user/articles -> retourne la collection articles de l'utilisateur (HTTP GET)
mon.api.com/read/user/article/12 -> retourne l'article id 12 de sa collection d'articles. (HTTP GET)
mon.api.com/create/user/article/12 -> crée l'article id 12 dans sa collection d'articles. (HTTP POST)
mon.api.com/update/user/article/12 -> met à jours l'article id 12 de sa collection d'articles. (HTTP PUT)
mon.api.com/delete/user/article/12 -> supprime l'article id 12 de sa collection d'articles. (HTTP DELETE)

L'ajout d'un paramètre dans l'url est redondant avec le verbe HTTP utilisé (GET,POST, PUT...). Il faut directement utiliser celui-ci pour déterminer l'action à réaliser. Sinon il se passe quoi par exemple si je fait un GET sur '/delete' ? La bonne pratique c'est de supprimer la redondance en supprimant tous les read/create/update/delete des urls ci-dessus. Le POST se fait sans id également car quand on créé une ressource on en connaît pas (encore) son identifiant.

je cloisonne le front et le back avec le préfixe d'url /user ou /admin

Ca part d'une bonne idée mais c'est également une mauvaise pratique car c'est peu flexible. Imagine tu as un troisième type d'user, tu fais quoi tu rajoutes un troisième préfixe ? Et si tes droits deviennent plus compliqué, voir même personnalisable par des clients eux-mêmes ? L'utilisation d'un préfixe devient ici extrêmement fastidieuse.
L'idée c'est que dans tous les cas tu vas devoir vérifier que l'utilisateur de l'API a bien le droit d'accéder à la ressource à laquelle il tente d'accéder en utilisant une méthode comme jwt (méthode vivement recommandée) donc autant en profiter aussi pour régler les droits d'accès de la personne connectée (toujours dans l'idée d'éviter la redondance).