Dois-je tolérer des paramètres inconnus?

Je conçois une API RESTful et confronté au problème de titre, reformulé pour plus de clarté:

Dois-je échouer rapidement si un client envoie un paramètre non reconnu? Par exemple,

http://example.com/api/foo?bar=true&paula=bean

Dans ce qui précède, barest un paramètre valide mais paulan'est pas spécifié par l'API. Devrais-je

Avertir le client de l'erreur
Échec rapide
Ignore ça

Si j'avertis le client, je ne peux émettre qu'un avertissement pour le premier paramètre, car il pourrait en envoyer un nombre presque infini, et le serveur a probablement de meilleures choses à faire. De même, en cas d'échec, il ne spécifierait que le premier paramètre non valide comme problème.

Je préfère l'échec à l'émission d'un avertissement pour forcer le programmeur à agir, car il pourrait sinon ignorer le problème et continuer à gaspiller des ressources, ou finir par se cultiver lui-même par inadvertance. Ne rien faire est encore pire à cet égard.

Mes arguments ont-ils un sens? Existe-t-il une pratique acceptée sur de telles choses?

rest api-design

— rath
source

Sur la base d'un petit test, tous les sites que j'ai testés ignorent simplement les paramètres inconnus que je leur ai fournis.

— Bart van Ingen Schenau

@BartvanIngenSchenau Idem ici. C'est bien pour les pages Web, mais je ne pense pas que ce soit correct pour une véritable API

— rath

Une préoccupation est la compatibilité ascendante. Si des arguments inconnus sont ignorés, il est possible de les utiliser dans les futures versions de manière à ce que les clients puissent programmer vers la nouvelle API et avoir un comportement raisonnable sur les anciens serveurs.

— walpen

@walpen C'est un point intéressant. L'utilisation d'URL versionnées, api/v1etc., s'en occuperait, mais cela ne permet toujours pas les mises à jour incrémentielles. +1

— rath

Vous y trouverez des avantages et des inconvénients du point de vue réel: des paramètres stricts et votre API .

— Remek Ambroziak

Réponses:

À mon avis, vous devez renvoyer un statut de demande non valide, afin que le client sache que ce qu'il essaie de faire n'est pas valide. Mon opinion à ce sujet est influencée par le concept selon lequel les API RESTful sont détectables . Si vous fournissez suffisamment d'informations à l'avance, le client n'essaie jamais de faire une demande non valide pour commencer. Si c'est le cas, alors il y a quelque chose de mal dans le code client et un échec rapide alertera le second sur ce bogue. Bien sûr, c'est une approche très puriste et peut ne pas être recommandée si votre API n'est pas détectable.

Une approche plus pragmatique peut être d'ignorer les paramètres invalides, mais dans tous les cas, assurez-vous de bien documenter le comportement.

— Canard en caoutchouc
source

En tant qu'extension: si un client envoie des paramètres inconnus / en lecture seule / obsolètes, cela signifie que le client attend un comportement qui ne sera pas satisfait. Et par conséquent, il est dangereux d'effectuer une action. Donc je suis d'accord, strictement Bad Request

— Stepan Stepanov

Merci @StepanStepanov, mais la philosophie «Soyez permissif dans ce que vous acceptez, explicite sur ce que vous envoyez» sous-tend une grande partie de l'architecture du Web. Dans cet esprit, je pourrais facilement écrire une réponse en opposition directe avec celle que j'ai déjà écrite.

— RubberDuck

J'ai googlé ceci)) Et la page sur la loi de Postel dit aussi "le code qui reçoit une entrée doit accepter une entrée non conforme tant que la signification est claire". Je pense que si le client nous envoie un paramètre inconnu, sa signification ne peut pas être claire. Si le client nous envoie un paramètre obsolète, c'est clair, il ne fonctionnera pas comme avant et comme le client l'attend. Si le client nous envoie un paramètre en lecture seule, il est clair, il ne sera pas écrit comme le souhaite le client.

— Stepan Stepanov

Si vous utilisez une API publique (ou une API qui sera utilisée par une autre équipe), je recommanderais une erreur de retour comme l'a suggéré @RubberDuck.

Si votre API ne sera consommée qu'à l'intérieur de votre équipe (ou uniquement par vous-même), il peut être plus facile d'ignorer les champs supplémentaires (par exemple, nécessite moins de code et plus facile à faire).

— Konstantin Petrukhnov
source