Quelle est la meilleure pratique pour exclure certains champs / données dans une réponse reposante si l'utilisateur demandant qu'il ne devrait pas être en mesure de voir toutes les données?
Exemple:
Les utilisateurs authentifiés et non authentifiés peuvent effectuer des demandes reposantes à /people.xml pour obtenir une liste complète des personnes. Cependant, seuls les utilisateurs authentifiés devraient pouvoir afficher toutes les informations. Les utilisateurs non authentifiés ne doivent contenir que les champs de premier et de nom de famille renvoyés (à l'exclusion des données de la date de naissance).
Le contrôleur de la personne doit-il vérifier l'authentification avant de créer la réponse? Si l'utilisateur est authentifié, ils obtiennent tout, sinon ils obtiennent un sous-ensemble seulement? Est-ce que cette casse-t-il des règles de repos où /people.xml peuvent envoyer deux résultats distincts?
5 Réponses :
Par le livre, le repos dit qu'une ressource devrait renvoyer le même résultat à chaque demande.
Je créerais un espace de noms avec "non authentifié" ou quelque chose et faire
/people.xml pour authentifié
et
/unauthentiqué/people.xml
Ils pourraient être le même contrôleur construire différents résultats XML pour chaque demande.
Oui, par définition, l'API ne devrait pas avoir plusieurs états basés sur des détails de l'invocation client. Soit fournir une API différente ou fournir des points d'entrée «privés». Votre code de mise en œuvre pourrait être identique, simplement appelé à plusieurs points de terminaison avec divers paramètres, de sorte que l'API était cohérente.
@ROBERTOKL Ça vous dérangerait de me contenter d'une référence faisant autorité où il est indiqué qu'une ressource devrait renvoyer le même résultat à chaque fois? Et pourriez-vous me dire si vous croyez que Get / actuelWeather pourrait être mis en œuvre de manière reposante?
@Darrel Miller Infoq.com/articles/Rest-Introduction Lisez la section communiquée STOVicialité. Je pense que cela explique pourquoi il devrait renvoyer la même ressource à chaque fois. Et cela répond à votre deuxième question. La ressource devrait toujours être la même, mais cela ne signifie pas que les données de cette ressource ne peuvent pas changer. Je pourrais changer le nom d'une personne et que les données seraient différentes. De la même manière que je peux changer la valeur météo actuelle. Si 2 navigateurs dans différents endroits accèdent à la même uri dans le même milliseconde, ils devraient voir exactement la même chose.
@robertokl vous êtes absolument correct. Cependant, j'ai peut-être mal interprété votre déclaration d'origine pour signifier quelque chose de différent. Je voulais juste clarifier ce que vous vouliez dire.
Je ne suis pas d'accord. /people.xml peut renvoyer différentes représentations de la ressource en fonction des informations d'authentification. Avoir deux URL pointant vers la même ressource dans différentes représentations viole le repos (pour la même raison, il devrait vraiment être / des personnes au lieu de /people.xml; la négociation de contenu se produit avec des en-têtes, sans l'utilisation de l'URI).
@ROBERTOKLL J'ai deux problèmes avec la réponse: 1. Quelle URI devrais-je utiliser si je veux faire référence à la "liste des personnes"? Repose des avantages d'avoir une URI pour chaque ressource, bien que ce ne soit pas une contrainte en soi. 2. Et si deux ensembles de références devraient renvoyer deux ressources, par exemple. Seule la liste des personnes qui sont mes amis? ( Modifier Je suppose que je suppose que si vous définissez une ressource pour signifier "la liste des personnes que vous êtes autorisés à voir" puis la réponse peut varier avec qui demande.)
"Selon les règles." Et quel livre est-ce? "Le repos dit qu'une ressource devrait renvoyer le même résultat à chaque demande." Donc, une API qui renvoie une liste d'objets doit toujours renvoyer une liste exacte de la même longueur contenant exactement les mêmes objets, non? (Je suis sarcastique. Cette réponse est waaaaaaay hors base.)
Vous pouvez utiliser l'option : seule code> de la méthode code> to_xml code> pour limiter les champs renvoyés par le contrôleur, c'est-à-dire: class Person
serialize_with_options(:anonymous) do
only :first_name, :last_name, :dob
end
end
class PersonController
def show
@person = Person.find(:params[:id])
respond_to do |format|
format.xml { render :xml => current_user.nil? ? @person.to_xml(:anonymous):
@person }
end
end
end
C'est une solution très sophistiquée. Si cela ne vous dérange pas de casser certaines règles de repos, j'irais avec cette option.
La granularité des données n'est pas spécifiée dans les règles de repos. La mise en œuvre peut décider de la portée des données exposées au client. Il s'agit d'une technique courante utilisée pour exposer plusieurs vues sur les données de modèle en fonction du privilège de l'utilisateur.
Considérez que différentes représentations des mêmes données (selon l'utilisateur) pourraient avoir des conséquences surprenantes si vous avez un cache quelque part au milieu. Si l'utilisateur entièrement authentifié effectue la demande d'abord, puis suivi de l'utilisateur «moindre», ils peuvent voir un résultat surprenant: la même vue que l'utilisateur entièrement authentifié avant. C'est parce qu'il n'y a pas de différence dans les deux demandes en ce qui concerne la cache (à moins que vous ne le preniez au courant de ces problèmes). Alors, marchez avec soin.
Je suggérerais également des espaces de noms séparés, comme proposé par Robert.
Les réponses aux demandes authentifiées sont par défaut non mises en cache et, si elles sont, je crois que le cache causerait un diable de nombreux autres problèmes :-). Cela dit, la mise en cache de la réponse d'une demande authentifiée pourrait être utile tant que le cache est une validation avec le serveur d'origine afin de savoir s'il peut servir la réponse mise en cache à l'autre client.
"... aurait pu avoir des conséquences surprenantes si vous avez une cache quelque part au milieu." C'est ce que les en-têtes de contrôle de cache sont destinés, en particulier l'en-tête de «Vary».
La même URL peut générer des représentations différentes, en fonction des en-têtes de demande. Par exemple, Accepter est couramment utilisé pour contrôler le format < / a> de la réponse (F.ex. XML ou JSON). De même, les en-têtes d'authentification pourraient être utilisés pour contrôler la quantité de retour pour une entité.
Non, ça va. C'est la même ressource, mais avec une représentation différente basée sur les informations d'authentification. Vous pouvez également servir différentes versions en fonction de ce que l'en-tête d'acceptation contenait (vous devez utiliser celui-ci au lieu d'extensions de fichier tels que .xml, à la manière), ou vous pouvez servir différentes versions de langue, ou vous pouvez rendre la page différente si la connexion est connectée. Dans l'utilisateur dispose d'options de personnalisation spécifiques définies. Tout est légal. Considérez un site Web qui a une boîte de connexion. Si vous êtes connecté, la page sera différente. C'est la même chose, sauf que cela n'affecte pas spécifiquement les informations ci-jointes en soi. Contrôler la mise en cache et ainsi de suite dans ces cas est exactement ce que le contrôle de la cache, varie et vos amis. Voir aussi http://www.subbu.org/blog / 2007/12 / Varier-Hauteur-forum-applications
@Trevor Voir les votes et les commentaires Je pense que vous devriez envisager sérieusement de changer la réponse acceptée à celle-ci.
Link fourni est mort.