Manière tranquille pour supprimer un tas d’éléments

Dans l’ article du wiki pour REST, il est indiqué que si vous utilisez http://example.com/resources DELETE, cela signifie que vous supprimez la collection entière.

Si vous utilisez http://example.com/resources/7HOU57Y DELETE, cela signifie que vous supprimez cet élément.

Je fais un SITE WEB, notez PAS SERVICE WEB.

J’ai une liste avec 1 case à cocher pour chaque élément de la liste. Une fois que j’ai sélectionné plusieurs éléments à supprimer, je vais autoriser les utilisateurs à appuyer sur un bouton appelé SUPPRIMER LA SÉLECTION. Si l’utilisateur appuie sur le bouton, une boîte de dialog js apparaîtra pour demander à l’utilisateur de confirmer la suppression. si l’utilisateur confirme, tous les éléments sont supprimés.

Alors, comment dois-je répondre à la suppression de plusieurs éléments d’une manière RESTAURÉE?

NOTE, actuellement pour DELETE dans une page Web, ce que je fais, c’est utiliser la balise FORM avec POST comme action, mais inclure une méthode avec la valeur DELETE, car c’est ce que d’autres utilisateurs de SO ont indiqué sur la suppression de RESTful pour la page Web .

Je pense que la réponse de rojoca est la meilleure à ce jour. Une légère variation pourrait être, pour supprimer le javascript de confirmer sur la même page, et au lieu de créer la sélection et de la redirect, en affichant un message de confirmation sur cette page. En d’autres termes:

De:
http://example.com/resources/

fait une

POST avec une sélection des identifiants pour:
http://example.com/resources/selections

qui, en cas de succès, devrait répondre avec:

HTTP / 1.1 201 créé et un en-tête Location pour:
http://example.com/resources/selections/DF4XY7

Sur cette page, vous verrez une boîte de confirmation (javascript) qui, si vous confirmez, fera une demande de:

DELETE http://example.com/resources/selections/DF4XY7

qui, en cas de succès, devrait répondre avec: HTTP / 1.1 200 Ok (ou tout ce qui est approprié pour une suppression réussie)

Une option consiste à créer une “transaction” de suppression. Donc, vous lancez quelque chose comme http://example.com/resources/deletes une nouvelle ressource consistant en une liste de ressources à supprimer. Ensuite, dans votre application, vous faites simplement la suppression. Lorsque vous effectuez la publication, vous devez renvoyer un emplacement de votre transaction créée, par exemple, http://example.com/resources/deletes/DF4XY7 . Un GET sur ceci pourrait renvoyer le statut de la transaction (complète ou en cours) et / ou une liste de ressources à supprimer.

Voici ce que Amazon a fait avec leur API REST S3.

Demande de suppression individuelle:

 DELETE /ObjectName HTTP/1.1 Host: BucketName.s3.amazonaws.com Date: date Content-Length: length Authorization: authorization ssortingng (see Authenticating Requests (AWS Signature Version 4)) 

Demande de suppression multi-object :

 POST /?delete HTTP/1.1 Host: bucketname.s3.amazonaws.com Authorization: authorization ssortingng Content-Length: Size Content-MD5: MD5 < ?xml version="1.0" encoding="UTF-8"?>  true  Key VersionId   Key  ...  

Mais l’ API Facebook Graph, l’API REST Parse Server et l’ API REST Google Drive vont encore plus loin en vous permettant de “regrouper” des opérations individuelles en une seule requête.

Voici un exemple de Parse Server.

Demande de suppression individuelle:

 curl -X DELETE \ -H "X-Parse-Application-Id: ${APPLICATION_ID}" \ -H "X-Parse-REST-API-Key: ${REST_API_KEY}" \ https://api.parse.com/1/classes/GameScore/Ed1nuqPvcm 

Demande par lot:

 curl -X POST \ -H "X-Parse-Application-Id: ${APPLICATION_ID}" \ -H "X-Parse-REST-API-Key: ${REST_API_KEY}" \ -H "Content-Type: application/json" \ -d '{ "requests": [ { "method": "POST", "path": "/1/classes/GameScore", "body": { "score": 1337, "playerName": "Sean Plott" } }, { "method": "POST", "path": "/1/classes/GameScore", "body": { "score": 1338, "playerName": "ZeroCool" } } ] }' \ https://api.parse.com/1/batch 

Je dirais DELETE http://example.com/resources/id1,id2,id3,id4 ou DELETE http://example.com/resources/id1+id2+id3+id4 . Comme “REST est un protocole d’architecture (…) [pas]” pour citer cet article de wikipedia, il n’y a pas, je crois, une seule façon de le faire.

Je suis conscient que ci-dessus n’est pas possible sans JS avec HTML, mais j’ai l’impression que REST était:

  • Créé sans penser à des détails mineurs comme les transactions. Qui aurait besoin d’opérer plus d’un seul article? Cela est en quelque sorte justifié dans le protocole HTTP, car il n’était pas destiné à servir d’autres pages Web statiques.
  • Pas nécessairement bien ajusté dans les modèles actuels – même du HTML pur.

Fait intéressant, je pense que la même méthode s’applique à PATCHing de plusieurs entités et nécessite de réfléchir à ce que nous entendons par nos URL, parameters et méthode REST.

  1. renvoyer tous les éléments ‘foo’:

    [GET] api/foo

  2. retourne les éléments ‘foo’ avec filtrage pour les identifiants spécifiques:

    [GET] api/foo?ids=3,5,9

Dans le sens où l’URL et le filtre déterminent “quels éléments nous traitons?”, Et la méthode REST (dans ce cas “GET”) dit “que faire avec ces éléments?”

  1. D’où PATCH plusieurs enregistrements pour les marquer comme lus

    [PATCH] api/foo?ids=3,5,9

..avec les données foo [lire] = 1

  1. Enfin, pour supprimer plusieurs enregistrements, cet endpoint est le plus logique:

    [DELETE] api/foo?ids=3,5,9

S’il vous plaît, comprenez que je ne crois pas qu’il y ait des “règles” à ce sujet – pour moi, cela “a du sens”

Comme il n’y a pas de moyen de le faire, ce que j’ai fait dans le passé est:

envoyez DELETE à http://example.com/something avec des données encodées xml ou json dans le corps.

Lorsque vous recevez la demande, vérifiez la valeur DELETE, si elle est vraie, puis lisez le corps pour ceux à supprimer.