¿Cuántos datos se deben requerir en una solicitud a un servicio web?

7

Cuando reciba datos de los clientes, ¿cuántos datos que les proporcionó en caso de que los necesite?

Por ejemplo, cuando los clientes piden un producto de un servicio web, ¿deberían simplemente proporcionar un código de producto? La otra alternativa sería requerir el código del producto nombre del producto y el precio del producto ect.

Siempre he construido servicios web de la forma anterior con el mínimo de datos devueltos, sin embargo, acabo de consumir otro servicio web que requiere la mayoría de los datos devueltos a ellos. ¿Cuáles son las ventajas de la segunda vía?

    
pregunta Tom Squires 11.10.2011 - 17:35

8 respuestas

13

Los maestros de servicios web Zen dirían:

  

Requerir la cantidad mínima absoluta de datos necesarios para completar la solicitud.

     

Responda con la mayor cantidad de datos que pueda ser útil para un solicitante.

La razón es que los datos adicionales requieren un trabajo adicional (e innecesario) en el lado del cliente e introducen más sobrecarga y más errores. El envío de "demasiados" datos en la respuesta generalmente es solo un pequeño trabajo adicional para el servidor, no requiere ningún esfuerzo para que el cliente ignore los campos que no necesita actualmente y reduce el número de solicitudes de cambio a largo plazo . De esta manera, su API será más fácil de usar y útil para una audiencia lo más amplia posible.

    
respondido por el James Anderson 27.10.2011 - 03:54
1

¿Estoy fuera de mi cabeza?

  • Requerir información redundante puede reducir (aunque no se puede eliminar con certeza) los errores relacionados con errores de tipo falso o de tipo "off-by-one". Enviar un pedido con un código de producto y una descripción del producto es menos probable que sea accidentalmente el código de producto incorrecto.
  • Puede forzar la interacción para usar su interfaz completa. Los raspadores web deberán mantener el estado de la sesión para tener suficiente información para ejecutar su servicio. Esto significa que puede limitarlos de manera más efectiva, si eso es un problema para usted.
  • No tienes que buscar nada; todo lo que hay en la solicitud: add_to_order(Product(**json.loads(request.data)))
respondido por el SingleNegationElimination 11.10.2011 - 17:45
0

Parece lógico que si envía datos al cliente, solo necesita una pequeña cantidad de datos en lugar de la población completa. Sin embargo, puede haber casos en que una interfaz se trate como una operación de guardado que puede hacer tanto actualizaciones como inserciones. Por lo general, una inserción requerirá que la población completa no envíe nada al cliente y no hay valores predeterminados predefinidos.

Algunos desarrolladores intentan reducir el número de interfaces porque menos interfaces significa menos puntos de falla y menor costo de mantenimiento. Aunque sí hace las cosas un poco más difíciles en el lado del cliente.

Sin embargo, dicho esto, si el rendimiento o el ancho de banda es un problema, debe intentar minimizar la cantidad de información que pasa entre el cliente y el servidor.

Este es un compromiso típico de rendimiento / simplicidad con el que los desarrolladores luchan.

    
respondido por el k rey 12.10.2011 - 19:18
0

En caso de que solo estemos hablando de los Servicios de datos para recuperar y almacenar objetos de entidad, es bueno tener la menor información posible. Esto le permite trabajar sin estado y le da un mayor control sobre la integridad de los datos (porque todos se administran en el nivel de datos).

Si, sin embargo, estamos hablando de servicios de integración, por ejemplo, que admiten transacciones de larga ejecución, el requisito de la cantidad de datos de publicación requeridos podría cambiar un poco más.

Las situaciones en las que se puede ofrecer a un cliente un precio determinado por un pedido específico pueden variar con el tiempo y por persona de ventas, pero la aceptación de dicho pedido puede demorar unos días. En ese caso, usted desea poder recuperar más que solo el orden, pero también algunos otros criterios. En ese caso, terminas con datos adicionales que proporcionan el contexto suficiente para reconstruir la situación.

Así que supongo que todo se reduce a poder tener suficiente información disponible para reconstruir la situación original y derivar las acciones necesarias para llevar a cabo.

    
respondido por el Carlo Kuip 25.10.2011 - 14:39
0

Cuando cambian los datos, es posible que necesite saber si el cliente solicita la operación según la versión actual. Entonces puede solicitar la verificación de todos los datos relevantes o proporcionar una versión / marca de tiempo y solicitarlo.

Si los datos cambian en grandes transacciones, la versión / marca de tiempo suele ser más fácil, pero si varios bits cambian de manera independiente, entonces tendría que proporcionar muchas versiones, por lo que solo es más fácil volver a solicitar los datos.

    
respondido por el Jan Hudec 25.10.2011 - 15:16
0

La solicitud debe contener información esencial, además de los filtros (si corresponde). El resultado debe contener los datos más importantes con los que un usuario puede utilizar la información para tomar una decisión. La cantidad de datos devueltos debe ser mínima para sistemas con gran número de usuarios.

Si su sistema está bien diseñado para servir a la empresa, es posible hacerlo.

Se requiere que la validación de GUI esté en línea con la naturaleza del negocio para que la cantidad de datos devueltos no sea excesiva. Por ejemplo, la búsqueda por nombre en un banco no debe permitir la búsqueda de una sola letra. Consígame todos los nombres que comiencen con "D" es una solicitud impar que la GUI debería evitar para que no recupere 100000 nombres.

La base de datos y las consultas deben diseñarse para que la navegación incremental sirva para este propósito.

    
respondido por el NoChance 27.10.2011 - 07:41
0

Debe evaluar cuidadosamente qué tipo de información necesita el cliente para enviar al servidor. En mi opinión, debe proporcionar el conjunto completo de información necesaria para operar solo a un servicio sin estado; por otro lado, prefiero enviar el conjunto mínimo de datos necesarios si el servicio está completo.

En un servicio web de llenado de pedidos (como usted describe) hay un conjunto de información relevante que el servidor debe mantener en una sesión y no debe proporcionarla el cliente. Piensa en el precio. ¿Qué sucede si un cliente malintencionado cambia el precio de 100 $ a 1 $?

Solicitar información redundante al cliente es una amenaza general para la seguridad. Dicho esto, no debe pedirle a un cliente que envíe ese tipo de datos. Los otros efectos secundarios positivos de esta práctica son que un cliente es más fácil de implementar y que la carga útil que transfiere es menor, pero considero que son efectos secundarios, ya que una buena política de seguridad sobre los datos transferidos los supera a todos.

    
respondido por el Terenzio Berni 27.10.2011 - 15:40
-1

Los mensajes del servicio web deben ser grueso, no hablador . Orientado a mensajes, no orientado a llamadas.

Un mensaje de solicitud o comando debe contener, como mínimo, suficiente información para:

  1. Valide a la persona que llama (autenticación / autorización).
  2. Valide la transacción (por ejemplo, una solicitud de actualización en un entorno de concurrencia optimista puede requerir el número de versión original)
  3. Ejecutar la transacción (identificadores, parámetros de búsqueda, etc.)

Además, normalmente habrá varios parámetros / elementos que querrá tener como opcional pero no requerido :

  • Listas de solicitudes secundarias, con un ID de correlación proporcionado por el cliente. Para cualquier operación dada, no requiera que el cliente realice solicitudes una por una; en su lugar, permítales agrupar todo en un solo mensaje y asegúrese de repetir sus ID de correlación en la respuesta. Esto es de vital importancia en entornos de alta latencia. (Los identificadores de correlación deben ser, por supuesto, opcionales, como la propia lista).

  • El tipo de datos (especialmente para REST): permite a los clientes especificar XML, JSON, etc.

  • Control sobre el tamaño y la forma del mensaje de respuesta, especialmente si la respuesta será muy grande y / o contendrá muchos elementos. Como mínimo, proporcione una manera de acelerar el número máximo de resultados. Las opciones de clasificación y paginación son mejores. Algunos servicios, por ejemplo, Salesforce, también proporcionan un "ID de consulta" que se puede utilizar para recuperar rápidamente las páginas de un resultado.

    Si es probable que haya una diferencia en el rendimiento, también podría considerar permitir que los clientes indiquen el nivel de anidamiento y / o qué relaciones cargar, usando un valor predeterminado razonable (generalmente todos o ninguno).

  • Una dirección de retorno (para mensajes unidireccionales).

  • Tiempos de espera, estrategias de manejo de errores, configuraciones de registro, o cualquier otra cosa que pueda ser de particular importancia para una transacción de larga duración. (De nuevo, use valores predeterminados razonables y valide las entradas)

  • Algunos servicios proporcionarán a los clientes un área para rellenar los datos de usuario que deseen, ya sea como una cadena o como un elemento XML. Piense en esto como la línea "memo" en un cheque. Es especialmente útil en situaciones de mensajería unidireccional.

No puedo enfatizar lo suficiente como para que esta segunda lista de opciones sea opcional y solo se use para mensajes que realmente se benefician de ella . No desea confundir a los clientes con una sorprendente variedad de opciones aparentemente inútiles.

Finalmente, intente mantener la información que es común a todos los mensajes (especialmente las credenciales) en los encabezados, no en el cuerpo. Si tiene información que es común a muchos mensajes pero no necesariamente a todos (la clasificación / paginación es un ejemplo común), entonces considere abstraerla en su propio tipo de datos (objeto de parámetro) . De esa manera, el cliente puede reutilizar la misma configuración una y otra vez si lo desea.

Por favor, no requiere todo tipo de controles y saldos, como nombres que tienen que coincidir con los ID, los ID de las sesiones, las sumas de control, los totales de control, o lo que sea. Debes confiar a tus clientes los privilegios que se te han otorgado. Si no confía en ellos para que envíen los datos correctos (de acuerdo con los requisitos de sus propios ), entonces tiene un problema comercial que resolver, no uno técnico.

    
respondido por el Aaronaught 30.10.2011 - 22:06

Lea otras preguntas en las etiquetas