Créer une demande avec POST, avec les codes de réponse 200 ou 201 et le contenu

Question

Supposons que j'écrive un REPOS de service dont le but est d'ajouter un nouvel élément de données, d'un système.

J'ai l'intention de POSTER

http://myhost/serviceX/someResources

Supposons que les œuvres, quel code dois-je utiliser? Et quel contenu que je pourrais revenir.

Je suis en train de regarder les définitions de codes de réponse HTTP et voir ces possibilités:

200: le Retour d'une entité décrivant ou contenant le résultat de l'action;

201: ce qui signifie CRÉÉ. Sens *La demande a été traitée et a entraîné une nouvelle ressource en cours de création. La ressource nouvellement créée peut être référencé par l'URI(s) retourné dans l'entité de la réponse, avec la plus spécifique de l'URI de la ressource donnée par un Emplacement champ d'en-tête. La réponse DOIT inclure une entité contenant une liste des caractéristiques de la ressource et de la localisation(s) à partir de laquelle l'utilisateur ou de l'agent utilisateur peut choisir la plus appropriée. L'entité format spécifié par le type de support donné dans le Type de Contenu de champ d'en-tête. *

Ce dernier semble plus en ligne avec la spécification Http, mais je ne suis pas clair du tout ce que

La réponse DOIT inclure une entité contenant une liste de ressources les caractéristiques et l'emplacement(s)

les moyens.

Recommandations? Les interprétations?

Answer 1

Je pense que atompub API REST est un excellent exemple d'un service restful. Voir l'extrait de code ci-dessous dans le atompub spec:

POST /edit/ HTTP/1.1
Host: example.org
User-Agent: Thingio/1.0
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Type: application/atom+xml;type=entry
Content-Length: nnn
Slug: First Post

<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
  <title>Atom-Powered Robots Run Amok</title>
  <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
  <updated>2003-12-13T18:30:02Z</updated>
  <author><name>John Doe</name></author>
  <content>Some text.</content>
</entry>

Le serveur signaux d'une création réussie avec un code d'état de 201. La réponse inclut un en-tête location en indiquant le Membre de l'Entrée de l'URI de l'Atome d'Entrée, et une représentation de l'Entrée dans le corps de la réponse.

HTTP/1.1 201 Created
Date: Fri, 7 Oct 2005 17:17:11 GMT
Content-Length: nnn
Content-Type: application/atom+xml;type=entry;charset="utf-8"
Location: http://example.org/edit/first-post.atom
ETag: "c180de84f991g8"  

<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
  <title>Atom-Powered Robots Run Amok</title>
  <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
  <updated>2003-12-13T18:30:02Z</updated>
  <author><name>John Doe</name></author>
  <content>Some text.</content>
  <link rel="edit"
      href="http://example.org/edit/first-post.atom"/>
</entry>

L'Entrée créé et retourné par la Collecte pourrait ne pas correspondre à l'Entrée Posté par le client. Un serveur PEUT modifier les valeurs des différents éléments dans l'Entrée, comme les atom:id, atom:updated, et de l'atome:l'auteur, les valeurs, et PEUT choisir de supprimer ou d'ajouter d'autres éléments et d'attributs, ou de modifier le contenu des éléments et des valeurs d'attribut.

Answer 2

Découvrez HTTP: Définitions de Méthode: POST.

L'action effectuée par la méthode POST n'aboutissent pas à une ressource qui peut être identifié par une URI. Dans ce cas, soit 200 (OK) ou 204 (Pas de Contenu) est la réponse appropriée statut, selon si oui ou non la réponse inclut une entité qui décrit le résultat.

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

Answer 3

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.19

C'est juste un virgules clé-valeur.

ETag: "xyzzy"

Il peut être n'importe quel type de données texte - je comprend généralement une chaîne JSON avec l'identifiant de l'élément créé. La facilité du test seul fait dont il vaille la peine.

ETag: "{ id: 1234, uri: 'http://domain.com/comments/1234', type: 'comment' }"

Dans cet exemple, le numéro d'identification de l'uri, et le type de la création de l'élément sont les "caractéristiques de la ressource et l'emplacement".

Answer 4

La sortie est en fait dépendante du type de contenu de la demande. Toutefois, au minimum, vous devriez mettre la ressource qui a été créé à l'Emplacement. Tout comme le Post-Rediriger-Get modèle.

Dans mon cas, je le laisse vide jusqu'à ce que demande contraire. Puisque c'est le comportement de JAX-RS lors de l'utilisation de la Réponse.créé().

Cependant, il suffit de noter que les navigateurs et les cadres comme Angulaire de ne pas suivre 201 automatiquement. J'ai noté que le comportement en http://www.trajano.net/2013/05/201-created-with-angular-resource/

Answer 5

Une autre réponse, j'aurais pour cela serait d'adopter une approche pragmatique et garder votre API REST contrat simple. Dans mon cas, j'avais refait mon API REST pour rendre les choses plus testable sans avoir recours à JavaScript ou XHR, de simples formulaires HTML et les liens.

Donc, pour être plus précis dans votre question ci-dessus, j'avais juste l'utilisation de code de retour 200 et ont retourné le message contient un JSON message que votre application peut comprendre. Selon vos besoins, il peut exiger que l'ID de l'objet qui vient d'être créée tellement l'application web peut obtenir les données dans un autre appel.

On remarque, dans ma refonte de l'API de contrat, POSTE les réponses ne doivent pas contenir de mettre en cache les données que les Postes ne sont pas vraiment cachable, afin de limiter l'IDs, qui peut être demandé et mis en cache à l'aide d'une requête GET.