Est-il acceptable en REST de renvoyer du contenu après un POST?

Question

Je suis en train d'utiliser RESTlet et j'ai créé une ressource. Je gère le POST en remplaçant la méthode acceptRepresentation.

Le client devrait m'envoyer des données, que je stocke ensuite dans la base de données, je définis la réponse sur 201 (SUCCES_CRÉÉ) et j'ai besoin de renvoyer certaines données au client, mais le type de retour de acceptRepresentation est void.

Dans mon cas, j'ai besoin de renvoyer un identifiant pour que le client puisse accéder à cette ressource.

Par exemple, si j'avais une ressource avec l'URL /resource et que le client envoie une requête POST, j'ajoute une nouvelle ligne dans la base de données et son adresse devrait être /resource/{id}. J'ai besoin d'envoyer {id}.

Est-ce que je fais quelque chose de mal ? Est-ce que les principes REST permettent de renvoyer quelque chose après un POST ? Si oui, comment puis-je le faire, et si non quel est le moyen de gérer cette situation ?

Answer 1

REST dit simplement que vous devriez vous conformer à l'interface uniforme. En d'autres termes, il dit que vous devriez faire ce que POST est censé faire selon la spécification HTTP. Voici la citation de cette spécification qui est pertinente,

Si une ressource a été créée sur le serveur d'origine, la réponse DOIT être 201 (Créé) et contenir une entité qui décrit le statut de la demande et fait référence à la nouvelle ressource, ainsi qu'un en-tête Location (voir section 14.30).

Comme vous pouvez le voir, vous avez deux endroits où vous pouvez indiquer au client où réside la ressource nouvellement créée. L'en-tête Location doit contenir une URL pointant vers la nouvelle ressource et vous pouvez également retourner une entité avec les détails.

Je ne suis pas sûr de la différence entre remplacer acceptRepresentation() et remplacer post() mais cet exemple montre comment renvoyer une réponse à partir d'un POST.

Answer 2

Je renoncerais à envoyer quoi que ce soit dans le corps de la réponse. Définissez simplement Location: sur l'URL (complète) de la ressource nouvellement créée.

Votre description suggère que c'est exactement la sémantique que vous:

1. POSTEZ une chose pour la créer
2. Répondez avec suffisamment pour savoir deux choses:
   1. Que la création s'est produite (le 201)
   2. Où trouver la nouvelle chose (l'en-tête Location)

Tout le reste est superflu.

Answer 3

Deux questions différentes :

Est-ce que le modèle d'application REST supporte le retour de données dans un POST ?

Je ne pense pas que REST l'interdise explicitement, mais le traitement préféré est expliqué dans la réponse de Darrel.

Est-ce que le framework RESTlet permet de retourner des données dans un POST ?

Oui, même s'il renvoie void, dans une classe qui étend Resource, vous avez un accès complet à l'objet Response via la méthode getResponse(). Donc, vous pouvez appeler getResponse().setEntity() avec les données que vous souhaitez.

Answer 4

Sortez-le dans le format demandé. Cela pourrait être:

    5483

Ou:

{ "type": "success", "id": 5483 }

Cela dépend de ce que vous avez l'habitude de faire. S'ils ne s'attendent pas aux données, ils devraient simplement les ignorer, mais tout client qui souhaite les gérer correctement devrait être capable de le faire.

Answer 5

Si vous répondez 201 Créé avec un corps d'entité, plutôt qu'une redirection de localisation, alors il est bon d'inclure un en-tête Content-Location pointant vers la ressource qui est représentée dans la réponse.

Cela évitera toute confusion potentielle - selon laquelle un client pourrait (à juste titre) supposer que l'entité de réponse représente en fait un nouvel état du 'créateur', et non la ressource créée.

> POST /collection
> ..nouvel élément..

< 201 Créé
< Location: /collection/1354
< Content-Location: /collection/1354
< Ceci est le nouvel élément qui a été créé