Rôle d'une API (REST)

Salut à tous,

Je travaille actuellement sur une application web. J’ai un front et un back-end qui discute via des requêtes http en JSON.
Le back-end est une API en NodeJS et les données sont dans une base MySQL. Jusque là tous va bien.

Mais voilà, j’ai l’impression que mon API me sert uniquement à deux choses :
- Identifier les utilisateurs. - "Traduire" les requêtes (GET, PUT, POST, DEL) entre le front et ma BDD.

Toutes ces requêtes sont au final assez génériques, la translation HTTP en SQL est toujours la même :

Du coup, j’ai décris mon schéma de BD dans un JSON. Ainsi, plutôt que de faire au moins quatre routes par table de la BD, j’en ai fait quatre génériques que j’instancie via les données de ce JSON.
Et c’est quand même beaucoup plus rapide de décrire une table dans un JSON que de créer toutes ces routes dans un script NodeJS.

Je voulais avoir votre avis sur ce système.
Est-ce que je pars dans quelque chose de totalement farfelu, sans aucun sens ?
Est-ce que cela fonctionne parce que j’ai une API "simple" qui ne sert qu’à fournir et modifier des données ? Et je serai bloqué alors pour autre une API plus complexe.
Est-ce que c’est magique de pouvoir mettre en place une API via la simple configuration de la connexion à la BDD et à sa description ?

Merci zeste !

ShiiFu

Salut,

C’est pas bête ce que tu fais, le problème c’est que t’as généralement pas 2 endpoints qui doivent se comporter pareil, dans ce type d’API.

Exemple, l’utilisateur peut :

• modifier tous les champs d’un article SAUF author_id
• seulement faire PUT sur /user/me, n’a accès à aucun autre verbe ou endpoint pour user
• peut faire DELETE sur /article/:pk seulement si cet article lui appartient

Tu vois, ce genre de contraintes sont pas faciles à encoder dans ton système générique.

Au passage :

• Je pense que tu confonds un peu PUT et POST, et PATCH peut-être aussi

  

• Le verbe HTTP pour supprimer est DELETE, pas DEL

• Le tag de ton topic est pas bon

Salut,

Ca fonctionne aujourd’hui, parce que tu fais uniquement du CRUD.

Tout l’intérêt d’une API REST c’est justement d’abstraire toute l’implémentation par derrière.

Mettre à jour le titre d’un article, aujourd’hui, dans ton code, ça revient à faire un update en base. Et si, demain, tu choisis un autre système de stockage ? Et si, tu souhaites agréger dans une même API plusieurs info de plusieurs tables.

Bref, tu devrais designer ton API sans te soucier une seule seconde de la façon dont les données sont représentées. Pense aux usages de ton API, au service qu’elle fournit, au contrat auquel elle t’engage vis à vis de tes utilisateurs. Une fois que c’est fait, soit tu adaptes le modèle de stockage pour avoir un bon compromis qualité de service fourni / efficacité de stockage, soit tu adaptes le design de l’API (éliminer certains services qui seraient trop coûteux en termes d’accès BDD) pour coller à tes contraintes techniques.

Comment tu renvoies une erreur métier propre du style "l’article que tu essaies de modifier n’existe pas".

Après je dis ça, on est absolument tous passé par ta phase de réflexion. Honnêtement, je pense que j’ai écris au moins 10 GenericMagicController dans ma vie de dévelopeur. Mais finalement, tu finis par bidouiller des trucs affreux pour avoir une gestion des erreurs respectueuse des standards, etc.

Est-ce que c’est magique de pouvoir mettre en place une API via la simple configuration de la connexion à la BDD et à sa description ?

Oui, tout plein d’outils de scaffolding permettent de faire ça. (le premier dont je me souviens c’était Ruby On Rails à l’époque). Mais en général, ils te génèrent le code qui va bien plutôt que de se contenter de "traduire" les paramètres de requête HTTP en paramètres de requête SQL.

Salut,

Merci pour vos réponses

En effet la gestion de droit n’est pas forcément simple à faire, mais cela reste faisable.

Oui, je me suis un peu embrouillé dans les verbes HTTP à l’écriture de mon sujet

C’est vrai que pour mon besoin actuel cela suffit. Je pensais à la possibilité de surcharger les routes pour les cas plus complexe.

J’avoue ne pas vraiment visualiser concrètement ce que ça donne quand tu me dis "tu devrais designer ton API sans te soucier une seule seconde de la façon dont les données sont représentées".

Aujourd’hui, c’est mon front en AngularJS qui vient gérer toutes les données brut reçu de l’API.
Mon application globale est assez complexe, mais les données et les associations entre elles sont simple.
Du coup, il est vrai que j’ai déporté "l’intelligence, le traitement" sur le front plutôt que sur le back-end. J’ai fait ça à cause d’un besoin initial qui était de pouvoir faire un client lourd en mode hors ligne qui peut se synchroniser par le suite. J’ai alors fait le minimum du côté API, ce qui n’est pas forcément le bon choix.

Hello,

Juste une petite correction. PUT c’est pour l’edition d’une ressource, et POST la création. Ouais je pensais aussi l’inverse en me basant sur les noms des verbes au début. :}