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).

[vallica]

Salut,

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.

En l'occurence le back sera dev from scratch, donc mon idée initiale était de rassembler les accès à la BDD du front et du back sur un seul seul point d'entrée/sortie : l'API REST.

Ais-je bon ?

L'ajout d'un paramètre dans l'url est redondant avec le verbe HTTP utilisé (GET,POST, PUT...).

Je suis d'accord et m'en tiens aux verbes HTTP

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)

J'utilise effectivement déjà les JWT pour l'app, coté front. Dans le payload je véhicule des roles/droits d'accès pour personnaliser l'affichage de l'app d'une part, et d'autre part coté API pour vérifier si l'user courant peut effectuer telle requête ou pas.

Donc pour résumer, tu penses que c'est cohérent d'utiliser une seule API pour le front et le back ?
A moi d'adapter le code métier de mes endpoints pour qu'ils se comporte différemment selon qu'ils soient appelées du front ou du back ?

[Spartacusply]

Mais je comprends pas, en fait il n'y a pas le front, le back et l'API, il y a le front ET le back : l'API EST le back. Je ne comprends pas quand tu parles de les dissocier, ça n'a pas de sens, que placerai tu du coup sous la notion du back ?

J'utilise effectivement déjà les JWT pour l'app, coté front. Dans le payload je véhicule des roles/droits d'accès pour personnaliser l'affichage de l'app d'une part, et d'autre part coté API pour vérifier si l'user courant peut effectuer telle requête ou pas.

C'est parfait ça

[vallica]

Mais je comprends pas, en fait il n'y a pas le front, le back et l'API, il y a le front ET le back : l'API EST le back. Je ne comprends pas quand tu parles de les dissocier, ça n'a pas de sens, que placerai tu du coup sous la notion du back ?

Disons que mon backoffice est codé en PHP, placé sur un serveur WEB, et propose donc une interface utilisateur en HTML/CSS/JS pour les admin.

Comment est-ce que ce backoffice doit accéder à la base de données selon toi ? En direct via PDO et donc des requêtes lancées sur la base ?

Ou bien n'est il pas plus propre de le faire lui même passer par l'API qui du coup centralisera tout le code nécessaire aux interactions avec la base.

Ainsi, si la structure de ta base de données évolue, tu n'as que le code de l'API à maintenir, et non le code de l'API+le code du backoffice.

[Spartacusply]

OK, donc il y a bien un existant.

Comment est-ce que ce back-office doit accéder à la base de données selon toi ? En direct via PDO et donc des requêtes lancées sur la base ?

Y'aurait pas d'existant il n'y a pas trop discussion : le "back" est en réalité un deuxième front qui doit utiliser les mêmes méthodes que le front "user". Là je suppose pas que tu vas pas tout balancer par terre donc c'est moins évident.
Ce que je ferai c'est de réutiliser ton code PHP existant et mettre à disposition certaines de ses ressources via des appels REST, mais que ton back actuel utilise toujours directement ces ressources sans relancer aucune requête HTTP. Ainsi tu n'as toujours qu'un seul code source à maintenir côté serveur et le front "admin" ne lance par des appels REST sur le même code source (je trouve ça lourd et inutile mais si cela semble plus "beau" logiquement parlant).

Je te donne mon avis personnel, ça se discute mais sans avoir plus de détail sur le projet c'est comme ça que je vois l'ensemble.

[vallica]

Re,

OK, donc il y a bien un existant.

Un léger existant, mais justement je compte re-écrire le backoffice pour passer sur quelque chose de plus facile à maintenir, d'où mon questionnement.

Prenons un cas simple : la création d'une app qui diffuse des articles et permet aux lecteurs de les commenter.

On est d'accord que l'on prévoir une API REST avec des endpoint pour que l'app puisse faire :
- GET liste d'article
- GET liste de commentaires par articles
- POST commentaire

Donc derrière tout ça, j'ai dans l'API REST des classes, des méthodes et des requêtes SQL qui font le job.

Maintenant si je veux que dans le backoffice un admin puisse faire les mêmes opérations pour accéder à la liste d'articles, voir les commentaires, les modérer.

Est-ce opportun de ré-écrire du code qui va refaire le même travail, des requêtes SQL en doublon avec celles de l'API, etc. ?

Je sais qu'auparavant pas mal de projets étaient conçus ainsi, mais n'est-ce pas laborieux de maintenir ces deux piles de code coté API et coté backoffice pour proposer sensiblement le même traitement sur les données ?

[Spartacusply]

Non, comme je l'ai dis ci-dessus ce n'est pas adapté. Maintenant tu as plusieurs applis/sites, codés uniquement en HTML/CSS/JS sans language serveur qui interagissent avec la même BDD via un seul point d'entrée, une seule API.

[vallica]

Compris, merci encore pour tes conseils ;-)