Mes collègues et moi mettons en œuvre un certain nombre de services HTTP reposants, et nous essayons de nous assurer que nous sommes a) après la spécification, et b) faire la chose "droite" où la spécification est à court de détails. Voici une situation particulière que nous sommes venus et recherchons des opinions de la communauté sur: p>
Supposons que vous ayez une ressource / personnes / Bob, et votre client va le mettre à jour avec un put . Le serveur peut produire des représentations pour / personnes / Bob dans application / JSON et texte / html. Le serveur peut interpréter des représentations pour / personnes / Bob dans l'application / JSON. P>
Compte tenu de cette demande: p>
PUT /People/Bob
Content-Type: application/json
Accept: application/xml
{ name: "Still Bob" }
5 Réponses :
+1 pour la philosophie de repos.
Sans connaissance détaillée de la spécification HTTP, je choisirais simplement l'une des options et documenter le devis et le choix.
Mes préférences seraient que le serveur ne peut pas répondre comme demandé, il ne faut pas traiter de la demande du tout.
Mais cela peut ne pas fonctionner dans certains scénarios, vous pourriez donc avoir à faire le contraire.
Hehe merci. Nous sommes très morts pour avoir les implémentations les plus belles de repos autour de vous. Je me penche dans cette direction (cautionnez toute la demande) et la principale chose qui me retient, c'est que cela nécessitera une réécrication d'une section de notre moteur hehehehe
Merci à tous ceux qui ont répondu. Je crois que nous allons aller avec défaillance de toute la demande, si je m'arrêterais d'être si paresseux.
Je discuterais "oui" en théorie, mais "Non" pour une application réelle.
Je vois la logique sans traitement s'il y a une erreur. Depuis que vous retournez un 406, pas un 500, je saurais que ce n'est pas une erreur dans les données que j'ai fournies, mais plutôt dans la manière dont le résultat est présenté à moi.
Cela dit, certaines applications ne rechercheront pas les codes d'erreur; Ils verront simplement qu'il est revenu avec une erreur plutôt que le XML qu'il a demandé et supposons que la transaction a échoué.
Je suppose que votre application de manutention / XML n'est pas un problème réel, mais aux fins de la question - si cela est effectivement déployé en tant que service réel, vous voudrez presque certainement pouvoir avoir un La représentation XML, comme c'est-ce que c'est (je soupçonne) l'interaction reposante la plus courante et de nombreux appelants seraient probablement codés en dur à utiliser XML.
Pour résumer: Si vous ne fournissez pas d'application / XML, alors je dirais, n'effectuez pas la mise à jour. Si vous gérez toutes les normes, mais que vous prévoyez de prévoir la contingence dans laquelle un utilisateur demandera à l'application / FoosomethingNonStandard, puis allez-y et effectuez la mise à jour, mais assurez-vous de répondre avec un 406.
Merci pour les commentaires. La question ne concerne pas vraiment XML ou un format particulier. Nous essayons de décider si le moteur qui choisit nos représentations devrait inspecter le type d'acceptation avant ou après le traitement de la demande. Le faire à la fin de la demande (que nous faisons maintenant) signifie répondre «oui»; Le faire au début de la demande signifie répondre «non».
La question est la suivante: si le serveur a-t-il effectué la mise à jour de / personnes / bob? p>
de La spécification HTTP , un 406 signifie: p>
La ressource identifiée par la demande est uniquement capable de générer des entités de réponse qui ont des caractéristiques de contenu non acceptables en fonction des en-têtes d'acceptation envoyés dans la demande. P>
Sauf demande à la tête, la réponse doit inclure une entité contenant une liste des caractéristiques de l'entité disponibles et de l'emplacement (s) d'emplacement (s) d'utilisateur ou d'utilisateur pouvant choisir celui qui est le plus approprié. Le format d'entité est spécifié par le type de support indiqué dans le champ d'en-tête Type de contenu. Selon le format et les capacités de l'agent utilisateur, la sélection du choix le plus approprié peut être effectuée automatiquement. Cependant, cette spécification ne définit aucune norme pour une telle sélection automatique. P>
Note: HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept headers sent in the request. In some cases, this may even be preferable to sending a 406 response. User agents are encouraged to inspect the headers of an incoming response to determine if it is acceptable.
Merci, des observations très astucieuses. Je suis tenté d'aller avec cette réponse (c'est ce que l'un de mes collègues suggéra de la BAT), mais je ne me sens pas dû à renvoyer quelque chose d'inutile au client. De plus, merci pour les conseils sur les types de médias, mais ceux que j'ai choisis pour cet exemple n'étaient que Vanilla et s'appliqueraient à toute combinaison de types de média.
Cela commence à sonner comme le type de couplage entre le client et le serveur qui est mieux évité. Quelle réalisable serait-il d'équiper le serveur avec une sortie XML ou d'équiper le client avec une entrée JSON? Si la réponse est "non très", alors que diriez-vous de renvoyer un 400 pour indiquer sans ambiguïté que la demande a échoué et que le serveur n'était pas mis à jour?
Un moyen de sortir de votre conundrum consiste à avoir un Un client "reposant" (ou au moins "" HTTP-Embrasting ")) saura de ne pas mettre à jour sa" page "actuelle et qu'il devra faire un avec succès retourner un 204 (pas de contenu). De cette façon, l'en-tête Accepter de la cliente n'est pas pertinent dans la question de savoir si la mise à jour est effectuée.
obtenir afin de rafraîchir son Vue du juste- Mettez ressource. Le accepter en-tête sur ce obtenez est maintenant, bien sûr, une préoccupation distincte de la mise à jour de l'atomicité.
Merci pour les commentaires, mais dans notre architecture, nous permettons d'avoir un organisme de réponse, qui est le moyen le plus efficace de communiquer les modifications, les mises à jour de validation et les messages de validation du côté serveur au client (y compris un corps sur 422, que nous utiliser pour les échecs de validation).
@Chris, j'ai un peu pensé que tu étais trop loin. :) et bien comprendre vouloir éviter une réponse supplémentaire-réponse. Je suis juste pensé que cette réponse pourrait être utile aux autres personnes ayant une question similaire et qui pourraient avoir des exigences différentes.
Je réussirais et retourneriez-en 200 à l'aide de la méthode riche suggère ci-dessus ou 406 et échouer. Le protocole ne permet pas une approche plus nuancée mélangeant 2xx (succès) avec des codes 4xx (erreur) afin que 4xx puisse être lu pour impliquer non le succès.
Cette réponse à une précédente question Stackoverflow pourrait être utile: Stackoverflow.com/Questtions/982351/...
Merci, Matt. Je pense que le fil clarifie un point de confusion, certaines personnes ont sur le type de contenu par rapport à l'acceptation (et 406 versus 415). Ce que je demande ici, c'est l'atomicité de la manipulation d'une demande puisque la spécification semble un peu courte ici.