• # Des API directement dans le navigateur ? Ou des routes

    Posté par (site web personnel, Mastodon) . En réponse au message Choix des URL "propres" pour du REST. Évalué à 10.

    J'ai l'impression que le terme REST a orienté la lecture de certains utilisateurs qui comprennent que tu veux faire des APIs, mais REST n'est pas spécifique aux APIs - cf la page wikipedia qui parle de Representational state transfer

    POST ou GET ?

    L'idée derrière une architecture est d'avoir qqchose de carré et si possible le + intuitif possible.

    Du coup je suggère d'utiliser :

    • GET pour des requêtes en lecture uniquement
    • POST pour tout le reste (création, modification, suppression)

    Ce principe fonctionne bien si tu es ok d'organiser la navigation via des formulaires (

    <form action="http://foo.com" method="POST">
 <button>Supprimer</button>
<form/>

    Si tu prévois de faire les choses via des liens <a href="xxx">Supprimer</a> alors il faut utiliser des GET et du coup l'archi serait plutôt :

    • GET pour des requêtes en lecture uniquement ou des action simples (exemple : supprimer une entité, activer/désactiver un utilisateur, etc)
    • POST pour tout le reste (création, modification)

    Routage

    À partir de ce qui a été dit au dessus, le routage suivant me semble clair et intuitif :

    • GET http://foo.bar/entities pour récupérer la liste
    • GET http://foo.bar/entities/<id> pour récupérer une entité précise
    • POST http://foo.bar/entities pour créer une entité
    • POST http://foo.bar/entities/<id> ou POST http://foo.bar/entities/<id>/update pour modifier une entité
    • POST http://foo.bar/entities/<id>/delete pour supprimer une entité

    Ce à quoi tu peux envisager d'ajouter des routes du style :

    • POST http://foo.bar/entities/<id>/activate pour activer une entité par exemple (en imaginant que tu aies un statut actif/inactif comme pour un utilisateur)

    • POST http://foo.bar/entities/<id>/archive pour activer une entité par exemple (en imaginant que tu aies un statut actif/inactif comme pour un utilisateur)

    D'une manière générale

    • cherche à standardiser ton architecture de routage. si tu mets la suppression en GET car accédé via un lien, alors utilise uniquement POST pour la création et modification et mets toutes les actions spécifiques en GET
    • dis-toi que tout ce qui est en GET va rester dans l'historique du navigateur et donc proposé en auto-complétion - donc potentiellement ça peut poser problème d'un point de vue utilisateur (par exemple : re-suppression sans faire exprès car mauvaise URL sélectionnée dans l'autocomplétion de firefox)
    • tout ce qui passe en GET est visible sur les intermédiaires. Tu trouves dans les logs Apache / NGINX les routes avec les paramètres GET. Typiquement, ne mets pas de données sensibles en GET (exemple : mot de passe, email, etc)
    • les paramètres GET sont généralement exploités pour faire du filtrage, par exemple : http://foo.bar/events/?owner=4&category=birthday&after=2023年10月16日T00:00:00
    • s'il s'agit de pages accessibles publiquement, les GET sont généralement crawlés par les moteurs de recherche

    J'ai fait un petit tour de ce qui me vient à l'esprit, n'hésite pas si tu veux approfondir des trucs.

    #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo