1. #1
    Membre averti
    Profil pro
    Inscrit en
    septembre 2005
    Messages
    738
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2005
    Messages : 738
    Points : 326
    Points
    326

    Par défaut Quelle structure (endpoints) pour une API REST

    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 !

  2. #2
    Membre éprouvé
    Homme Profil pro
    Développeur multimédia
    Inscrit en
    juillet 2004
    Messages
    680
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur multimédia
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : juillet 2004
    Messages : 680
    Points : 1 141
    Points
    1 141

    Par défaut

    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)

  3. #3
    Membre averti
    Profil pro
    Inscrit en
    septembre 2005
    Messages
    738
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2005
    Messages : 738
    Points : 326
    Points
    326

    Par défaut

    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)

  4. #4
    Membre éprouvé
    Homme Profil pro
    Développeur multimédia
    Inscrit en
    juillet 2004
    Messages
    680
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur multimédia
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : juillet 2004
    Messages : 680
    Points : 1 141
    Points
    1 141

    Par défaut

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

  5. #5
    Membre averti
    Profil pro
    Inscrit en
    septembre 2005
    Messages
    738
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2005
    Messages : 738
    Points : 326
    Points
    326

    Par défaut

    Compris, merci encore

  6. #6
    Membre expert
    Avatar de Spartacusply
    Homme Profil pro
    Développeur Web
    Inscrit en
    mai 2011
    Messages
    1 689
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mai 2011
    Messages : 1 689
    Points : 3 296
    Points
    3 296

    Par défaut

    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).
    Un message utile vous a aidé ? N'oubliez pas le

    www.simplifions.fr - Simplifier vos comptes entre amis !

  7. #7
    Membre averti
    Profil pro
    Inscrit en
    septembre 2005
    Messages
    738
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2005
    Messages : 738
    Points : 326
    Points
    326

    Par défaut

    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 ?

  8. #8
    Membre expert
    Avatar de Spartacusply
    Homme Profil pro
    Développeur Web
    Inscrit en
    mai 2011
    Messages
    1 689
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mai 2011
    Messages : 1 689
    Points : 3 296
    Points
    3 296

    Par défaut

    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
    Un message utile vous a aidé ? N'oubliez pas le

    www.simplifions.fr - Simplifier vos comptes entre amis !

  9. #9
    Membre averti
    Profil pro
    Inscrit en
    septembre 2005
    Messages
    738
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2005
    Messages : 738
    Points : 326
    Points
    326

    Par défaut

    Citation Envoyé par Spartacusply Voir le message
    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.

  10. #10
    Membre expert
    Avatar de Spartacusply
    Homme Profil pro
    Développeur Web
    Inscrit en
    mai 2011
    Messages
    1 689
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mai 2011
    Messages : 1 689
    Points : 3 296
    Points
    3 296

    Par défaut

    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.
    Un message utile vous a aidé ? N'oubliez pas le

    www.simplifions.fr - Simplifier vos comptes entre amis !

  11. #11
    Membre averti
    Profil pro
    Inscrit en
    septembre 2005
    Messages
    738
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2005
    Messages : 738
    Points : 326
    Points
    326

    Par défaut

    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 ?

  12. #12
    Membre expert
    Avatar de Spartacusply
    Homme Profil pro
    Développeur Web
    Inscrit en
    mai 2011
    Messages
    1 689
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mai 2011
    Messages : 1 689
    Points : 3 296
    Points
    3 296

    Par défaut

    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.
    Un message utile vous a aidé ? N'oubliez pas le

    www.simplifions.fr - Simplifier vos comptes entre amis !

  13. #13
    Membre averti
    Profil pro
    Inscrit en
    septembre 2005
    Messages
    738
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2005
    Messages : 738
    Points : 326
    Points
    326

    Par défaut

    Compris, merci encore pour tes conseils ;-)

Discussions similaires

  1. Quel langage pour une API REST web "haute performance" ?
    Par onepix dans le forum Langages de programmation
    Réponses: 0
    Dernier message: 10/06/2017, 19h22
  2. Réponses: 0
    Dernier message: 10/10/2016, 11h43
  3. Format d'un JSON pour une API REST
    Par pierapi dans le forum Langage
    Réponses: 2
    Dernier message: 17/09/2015, 16h15
  4. Réponses: 2
    Dernier message: 06/12/2011, 15h26
  5. Réponses: 4
    Dernier message: 05/06/2005, 15h05

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo