it-swarm-es.com

¿Es una práctica común validar respuestas de API de terceros?

Estoy trabajando en una aplicación web PHP que depende de algunos servicios de terceros. Estos servicios están bien documentados y son proporcionados por organizaciones bastante grandes.

Me siento paranoico cuando trabajo con respuestas de estas API, lo que me lleva a escribir un código de validación que valida que las respuestas coincidan con la estructura y los tipos de datos especificados en la documentación. Esto se debe principalmente al hecho de que está fuera de mi control y si confío ciegamente en que los datos serán correctos y no lo son (tal vez alguien cambie la estructura json por accidente), podría provocar un comportamiento inesperado en mi aplicación.

Mi pregunta es, ¿crees que esto es exagerado? ¿Cómo manejan los demás esta situación?

42
Darren Findlay

Absolutamente. Para empezar, nunca se sabe que alguien no ha pirateado su conexión y la respuesta que recibe no proviene en absoluto de la API.

Y en algún momento de las últimas dos semanas, creo que Facebook cambió una API sin previo aviso, lo que provocó el bloqueo de muchas aplicaciones de iOS. Si alguien hubiera verificado la respuesta, la API habría fallado, pero sin bloquear la aplicación.

(Un caso muy agradable, escuché por qué es necesaria la validación: un servidor proporcionó información sobre los productos que un cliente podía comprar. Para los vestidos, incluían el tamaño del vestido del Reino Unido como un número entero, generalmente 36 a 52. Excepto para un vestido, el tamaño era un cadena "40-42". Sin validación que fácilmente podría ser un bloqueo.)

64
gnasher729

La API de otra persona es su interfaz externa. No deberías confiar ciegamente en nada que cruce ese límite. Sus futuros depuradores le agradecerán por no propagar los errores del otro sistema en los suyos.

40
Ross Patterson

¿Su límite API también es un límite de confianza?

Como te estás comunicando con un sistema remoto, eso es casi una certeza. Incluso si el sistema remoto en sí pudiera ser confiable , el medio podría no serlo.

Si no se verifica de manera exitosa y consistente todos los datos que no son de confianza, se puede producir un bloqueo en el mejor de los casos, en el peor de los casos, silenciar la adquisición hostil.

¿Es estable la API?

Incluso una API confiable puede no ser estable, en cuyo caso se necesita una verificación adicional y un plan para retirarse, hasta negar el servicio hasta que se solucione.

¿La implementación detrás de la API está bien probada, es madura y confiable?

No importa si la API es estable si la implementación no está a la altura.

Siempre recuerde que hay una compensación

Más pruebas significan más código que puede contener errores, y rara vez se ejercitará.

Este código debe ser escrito, mantenido y depurado, todo lo cual agota el esfuerzo necesario en otros lugares también.

Además, probar exhaustivamente el caso de falla es algo difícil e imposible sin burlarse de la API completa, lo que probablemente deje el error sin descubrir y acumule más, incluso si es más lento que los comentarios.

Por lo tanto, algunas API simplemente se utilizan para funcionar, mientras que otras se verifican (o al menos deberían) verificarse en cada llamada al menos en cierta medida.

17
Deduplicator

Paranoico o no depende de cuán robusto debe ser su software.

Creo que si sus cheques tienen costos de implementación adicionales mínimos, entonces están bien.

Ejemplo:

  • si se comunica con los servicios a través de XML, la verificación estructural se puede hacer a través de un esquema XSD.
  • en Java/C # puede tener declaraciones de protección que arrojen una excepción, si el contrato de API está roto
    • Ejemplo: si recibe un cumpleaños de un servicio externo, la declaración de protección assert(birthday > '1900-01-01' and birthday < '2050-01-01') arrojará una excepción si el cumpleaños tiene un valor no plausible
3
k3b

Absolutamente. Esto nos ha sorprendido con las API de Microsoft, por ejemplo, y ni siquiera estamos configurados para iniciar sesión en nuestra aplicación de función Azure . Entonces, todo lo que vimos fue que las solicitudes a nuestros puntos finales fallaron. Cambió sin previo aviso entre las pruebas manuales/ UAT y el uso real en vivo de nuestra aplicación.

Nuestras pruebas unitarias todavía funcionaron, por supuesto, porque usaron el esquema de la documentación de Microsoft (que no había sido actualizado). ¡Solo lo sabía porque algún otro desarrollador amable comentó la documentación de Microsoft!

Asegúrese de registrar lo que realmente obtiene como solicitud de API externas en su punto final/como respuesta a su llamada y arroje errores significativos (según corresponda) en su aplicación.

En realidad, esto me da la voluntad con nuestro proyecto actual, que se basa en muchas API externas: tenemos funciones de monitoreo y E2E pruebas con Cypress para funciones vitales que se ejecutan de vez en cuando, así que al menos sabemos cuándo sucede. Todavía estamos trabajando en cómo saber de antemano de manera confiable ...

3
kpollock

Sí, pero en la mayoría de los casos esa no debería ser su preocupación personal.

Para la mayoría de los idiomas, hay analizadores que analizan una respuesta JSON nativa (o cualquiera que sea su idioma de transferencia) en sus objetos internos. Vienen con todas las opciones para considerar diferentes estilos de escritura, comprender casos de esquina, caracteres de escape, codificaciones de caracteres especiales, etc. Su código de validación es utilizado por miles de otras aplicaciones. Debería usar uno de estos analizadores si es posible y confiar en sus métodos de validación en lugar de validar la sintaxis usted mismo. Es decir. deberían lanzar excepciones, devolver códigos de error o de lo contrario quejarse si la entrada no coincide con lo que especificó (campos faltantes, cadenas que no coinciden con su patrón definido, etc.).

La única validación que puede querer hacer usted mismo en su propio código es que la respuesta tenga sentido para su lógica empresarial. Sin embargo, no intente reimplementar el otro servicio, no tiene sentido validar completamente que su respuesta es correcta: si puede hacerlo localmente, entonces no necesita llamarlos. (A menos que se ocupe de asuntos totalmente delicados/problemas difíciles, puede llamar a múltiples servicios y combinar sus resultados). Lo que puede hacer cuando desea protegerse contra un nivel extremo de desastres de respuestas maliciosas es detectar respuestas que están fuera de los límites. Es decir. bloquee una transacción en su servicio de alquiler de bicicletas si la factura calculada externamente para un solo cliente supera los 1000 $ o algo así. Pero tenga cuidado, uno fácilmente pasa por alto los casos de esquina que son válidos (por ejemplo, un cliente "virtual" que paga los alquileres de toda su empresa durante un año).

3
Frank Hopkins

Su validación no debe ser restrictiva. Existe el patrón de "lector tolerante". Significa que debe ser lo más tolerante posible al consumir datos de otros servicios. Por otro lado, está el patrón "Escritor Magnánimo". Juntos, ayudan a producir sistemas de comunicación más robustos.

Por ejemplo, en una interfaz basada en JSON, probablemente debería permitir propiedades desconocidas. Esto permite que el otro lado agregue nuevas propiedades sin romper su lado.

3
user355880