¿Debo ser permisivo con los parámetros desconocidos?

Estoy diseñando una API RESTful y me enfrenté al problema del título, reformulado para mayor claridad:

¿Debo fallar rápidamente si un cliente envía un parámetro no reconocido? Por ejemplo,

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

En lo anterior, bares un parámetro válido pero paulano está especificado por la API. Debería

Avisar al cliente del error
Fallar rapido
Ignoralo

Si le advierto al cliente, solo puedo emitir una advertencia para el primer parámetro, ya que podrían estar enviando un número casi infinito de ellos, y el servidor presumiblemente tiene mejores cosas que hacer. De manera similar, cuando falla, solo especificaría el primer parámetro inválido como el problema.

Prefiero el fracaso en lugar de emitir una advertencia para obligar al programador a tomar medidas, ya que de lo contrario podrían ignorar el problema y seguir desperdiciando recursos, o terminar cargando a sí mismos sin darse cuenta. No hacer nada es aún peor en ese sentido.

¿Mis argumentos tienen sentido? ¿Existe una práctica aceptada en tales cosas?

rest api-design

— rath
fuente

Basado en una pequeña prueba, todos los sitios que probé simplemente ignoran los parámetros desconocidos que les proporcioné.

— Bart van Ingen Schenau

@BartvanIngenSchenau Lo mismo aquí. Está bien para las páginas web, pero no creo que esté bien para una API real

— rath

Una preocupación es la compatibilidad hacia adelante. Si se ignoran los argumentos desconocidos, es posible usarlos en futuras versiones de tal manera que los clientes puedan programar en la nueva API y aún así obtener un comportamiento razonable en los servidores antiguos.

— walpen

@walpen Ese es un punto interesante. El uso de URL versionadas, api/v1etc. se encargaría de eso, pero aún no permite actualizaciones incrementales. +1

— rath

Allí puede encontrar algunos pros y contras desde una perspectiva real en vivo: Parámetros estrictos y su API .

— Remek Ambroziak

Respuestas:

En mi opinión, debe devolver un estado de Solicitud no válida, para que el cliente sepa que lo que está tratando de hacer no es válido. Mi opinión sobre esto está influenciada por el concepto de que las API RESTful son reconocibles . Si proporciona información suficiente por adelantado, el cliente nunca intenta hacer una solicitud no válida para empezar. Si lo hace, entonces hay algo mal en el código del cliente y la falla rápida alertará al segundo sobre este error. Por supuesto, ese es un enfoque muy purista y puede no recomendarse si su API no es reconocible.

Un enfoque más pragmático puede ser ignorar los parámetros inválidos, pero de cualquier manera, asegúrese de documentar bien el comportamiento.

— RubberDuck
fuente

Como extensión: si un cliente envía algunos parámetros desconocidos / de solo lectura / obsoletos, eso significa que el cliente espera algún comportamiento que no se cumplirá. Y por lo tanto, es peligroso realizar cualquier acción. Así que estoy de acuerdo, estrictamente mala solicitud

— Stepan Stepanov

Gracias @StepanStepanov, pero existe la filosofía "Sea permisivo en lo que acepta, explícito sobre lo que envía" que subyace en gran parte de la arquitectura de la web. Con eso en mente, podría escribir fácilmente una respuesta en oposición directa a la que ya escribí.

— RubberDuck

He buscado en Google esto)) Y la página sobre la ley de Postel dice también que "el código que recibe información debe aceptar información no conforme siempre que el significado sea claro". Creo que si el cliente nos envía algún parámetro desconocido, su significado no puede ser claro. Si el cliente nos envía un parámetro en desuso, está claro, no funcionará como antes y como el cliente espera. Si el cliente nos envía un parámetro de solo lectura, está claro, no se escribirá como el cliente lo desee.

— Stepan Stepanov

Si haces una API pública (o una API que será utilizada por otro equipo), recomendaría devolver el error como sugirió @RubberDuck.

Si su API se consumirá solo dentro de su equipo (o solo usted), puede ser más fácil ignorar los campos adicionales (por ejemplo, requiere menos código y es más fácil de hacer).

— Konstantin Petrukhnov
fuente