Forum Programmation.web Choix des URL "propres" pour du REST

Posté par  (Mastodon) . Licence CC By‑SA.
Étiquettes : aucune
3
23
nov.
2023

Je Pythonne un peu avec Flask.

Assez rapidement, quelle que soit l'appli, on va manipuler des objets, les créer, les modifier, les supprimer etc. Je suis vite tombé sur REST et les différents verbes du HTTP mais si j'ai bien compris ça ne marche pas quand on se limite à un browser qui ne fait que du GET et POST.

Si pour lire un objet j'y accède via monsite/objet/<id> en GET, quelle URL adopter pour du DELETE par exemple ? Un truc style monsite/objet/<id>/delete en POST ?

Y a-t-il des us et coutumes particuliers ?

Merci !

  • # OpenAPI

    Posté par  . Évalué à 4. Dernière modification le 23 novembre 2023 à 10:53.

    Hello,

    tu peux suivre la norme OpenAPI.

    Comme tu le dis, typiquement pour faire une suppression, on utilise la méthode DELETE de HTTP. Mais après tout, tu peux l'accepter avec un GET ou un POST, c'est ton API :).

    L'idée c'est que souvent, dans le navigateur, les méthodes d'accès à l'API vont être exécutées par du JavaScript, et JavaScript peut préciser s'il veut faire du GET, POST, DELETE.

    Il y a sans doute d'autres "normes".

    • [^] # Re: OpenAPI

      Posté par  (Mastodon) . Évalué à 3.

      L'idée c'est que souvent, dans le navigateur, les méthodes d'accès à l'API vont être exécutées par du JavaScript

      Oui voilà j'ai pas précisé que je veux faire sans JS.

      Je vais jeter un oeil à OpenAPI, merci.

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: OpenAPI

        Posté par  . Évalué à 2.

        Ah alors sans JavaScript, et si tu veux que ça fonctionne depuis un navigateur (drôle d'idée pour une API mais bon, je comprend l'envie de simplicité), tu es condamné à insérer le verbe dans l'URL1.

        Un peu dans ce genre pour les quatre opérations CRUD :

        CREATE: https://api.example.com/v1/post/issue/4576
READ:   https://api.example.com/v1/get/issue/4576
UPDATE: https://api.example.com/v1/put/issue/4576 (ou /update/)
DELETE: https://api.example.com/v1/delete/issue/4576

        1. Mais peut-être qu'on peut faire des liens en précisant le verbe genre de nos jours ? ↩

        • [^] # Re: OpenAPI

          Posté par  (site web personnel) . Évalué à 2.

          Je ne suis pas sûr de comprendre la contrainte sur le navigateur qui ne fait que GET et POST. Pour faire du REST (complet) depuis un navigateur, des greffons comme RESTED existent, et offrent toute la panoplie ?

          Debian Consultant @ DEBAMAX

          • [^] # Re: OpenAPI

            Posté par  (Mastodon) . Évalué à 3.

            Oui mais je ne peux pas demander à mes utilisateurs de mettre un greffon rien que pour cette appli.

            En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

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

    Posté par  (site web personnel, Mastodon) . É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-16T00: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.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.