Est-il autorisé par le REPOS au retour de contenu après le POST?

Je suis à l'aide de RESTlet et j'ai créé une ressource. J'ai poignée POST en remplaçant acceptRepresentation méthode.

Le client doit m'envoyer des données, puis-je stocker dans la base de données, des réponses à 201 (SUCCESS_CREATED) et j'ai besoin de retourner des données vers le client, mais le type de retour de acceptRepresentation est void.

Dans mon cas, j'ai besoin de revenir à l'identifiant de sorte que le client peut accéder à cette ressource.

Par exemple, si j'avais une ressource située à l'URL /resource et le client envoie une requête POST j'ai ajouter une nouvelle ligne dans la DB et son adresse doivent être /resource/{id}. J'ai besoin d'envoyer {id}.

Je fais quelque chose de mal? Ne RESTE principes permettent de retourner quelque chose après? Si oui, comment puis-je le faire, et si non quelle est la façon de gérer cette situation?

  • Voir Thom, la réponse à comment définir le corps de la réponse de l'intérieur acceptRepresentation().
InformationsquelleAutor del-boy | 2009-12-02
  1. 87

    RESTE juste dit que vous devez vous conformer à l'interface uniforme. En d'autres termes, il dit que vous devriez faire ce POST est censé faire que par la HTTP spec. Voici la citation de cette spécification qui est pertinent,

    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 l'état de l'
    demande et se réfère à la nouvelle
    de ressources, et un en-tête location
    (voir la section 14.30).

    Comme vous pouvez le voir à partir de cela, vous avez deux endroits où vous pouvez indiquer au client où la ressource nouvellement créée réside. L'Emplacement de la tête doit avoir une URL qui pointe vers la nouvelle ressource et vous pouvez retourner à une entité avec les détails aussi.

    Je ne suis pas sûr de ce que la différence entre le remplacement acceptRepresentation() et primordial, post (), mais cette exemple montre comment retourner une réponse d'un POST.

    • Voir Thom, la réponse à comment définir le corps de la réponse de l'intérieur acceptRepresentation().
    • La spécification HTTP citation n'interdit pas une réponse, si vous regardez dans la Section 6, il est clair: il est autorisé: Request and Response messages MAY transfer an entity if not otherwise restricted by the request method or response status code. An entity consists of entity-header fields and an entity-body, although some responses will only include the entity-headers.
    • Ce n'était pas mon intention d'en déduire que le corps de la réponse n'a pas été autorisé. La partie de la spec que j'ai cité plus précisément dit "et contenir une entité". J'aurais du être plus clair dans mon texte.
    InformationsquelleAutor Darrel Miller
  2. 14

    J'avais renoncer à envoyer quoi que ce soit dans le corps de la réponse. Juste définir l'Emplacement: à la (pleine) URL de la ressource nouvellement créée.

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

    1. POST une chose à créer
    2. Répondre avec suffisamment de savoir deux choses:
      1. Que la création est arrivé (201)
      2. Où trouver de la nouvelle chose (l'Emplacement de l'en-tête)

    Tout le reste est superflu.

    • Pas que Wikipédia est toujours une bonne source, mais ça affirme également "[...] afin De fournir des informations sur l'emplacement d'une ressource nouvellement créée. Dans ce cas, l'Emplacement de l'en-tête doit être envoyé avec un code de statut HTTP de 201 ou 202."
    • POSTE peut exécuter une logique qui crée une ou plusieurs ressources. Le résultat du traitement peut être nécessaire par le client. Donc, de retour dans la réponse évite la nécessité d'effectuer un ou plusieurs REÇOIS des appels à l'API. Les données créées/modifiées par la méthode POST peut-être pas (et n'est pas souvent) superflu pour le client.
    InformationsquelleAutor cdent
  3. 10

    Deux questions différentes:

    Fait le RESTE, demande modèle de support de données de retour dans un POST?

    Je ne pense pas que le REPOS interdit explicitement, mais le traitement de choix est écrit dans Darrel de réponse.

    Ne le RESTlet framework permettent de retourner des données dans un POST?

    Oui, même si il revient vide, dans une classe qui s'étend de Ressources, vous avez un accès complet à l'objet de la Réponse de l'objet via le getResponse() la méthode. Vous pouvez donc appeler getResponse().setEntity() avec toutes les données que vous voulez.

    InformationsquelleAutor Thom
  4. 6

    De sortie quel que soit le format est demandé. Qui pourrait être:

    <success>
    <id>5483</id>
</success>

    Ou:

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

    Cela dépend de ce que vous faites habituellement. Si ils attendons pas les données, il faut juste l'ignorer, mais un client qui veut le gérer correctement devrait être en mesure de.

    • Ok, j'ai deux formats (html et xml). Je sais comment gérer le type de format demandé, mais je ne sais pas comment ajouter des données de réponse. représenter méthode retourne la Représentation, j'ai donc juste retour de ce que jamais je veux, mais acceptRepresentation est la méthode void, donc je ne peux pas renvoyer toutes les données...
    InformationsquelleAutor Samir Talwar
  5. 1

    Si vous répondez 201 Créé avec un corps d'entité, plutôt que d'un Emplacement de redirection, alors c'est une bonne idée d'inclure un Contenu de l'Emplacement de l'en-tête pointant vers la ressource qui est représenté dans la réponse.

    Cela permettra d'éviter tout risque de confusion - dans lequel un client peut (légitimement) supposons que l'entité de réponse représente, en réalité, un nouvel état du "créateur", et non pas à la création de la ressource.

    > POST /collection
> ..new item..

< 201 Created
< Location: /collection/1354
< Content-Location: /collection/1354
< <div class="item">This is the new item that was created</div>
    • Je pense que Content-location est pour un but différent. La spécification HTTP, dit-Content-location n'est pas défini pour le POST et le METTRE. L'Emplacement de l'en-tête est utilisé avec un 201-Créer. Retour d'un Emplacement ne fait pas automatiquement faire une redirection, vous avez besoin d'un 3XX code de réponse pour ça.
    • L'emplacement de l'en-tête est utilisé (dans un 201 réponse) pour indiquer où la ressource créée est situé; il n'est pas pertinent pour le corps de l'entité de la réponse qu'il accompagne. Mon point est que si vous vouliez inclure la ressource créée dans le 201 réponse elle-même (plutôt que de diriger/rediriger le client vers un autre URI) puis le contenu de l'en-tête location serait une bonne idée. C'est probablement "bending the rules" un peu, mais c'est plus efficace que d'exiger une autre requête/réponse du cycle pour obtenir l'état de la nouvelle ressource pour le client.
    • Faire sens pour moi. Je n'ai jamais utilisé le Contenu de l'Emplacement de l'en-tête avant.
    • si le client est un homme avec un navigateur, de retour 201 avec l'Emplacement de l'en-tête n'a pas de sens. L'utilisateur ne saura pas quoi faire avec elle. si le client est un robot, il peut être programmé savoir comment traiter avec elle - comme un suivi à OBTENIR sur l'Emplacement.
    • Je crois que le REPOS a signifié pour la conception d'Api, où A n'est pas un Agent Utilisateur qui cherche un peu de HTML pour le rendu.
    InformationsquelleAutor Mike