tutorial - servicios rest ejemplo
Forma RESTful de crear múltiples elementos en una sola solicitud (7)
Aunque las operaciones masivas (por ejemplo, creación por lotes) son esenciales en muchos sistemas, no se abordan formalmente con el estilo de arquitectura RESTful.
Descubrí que POSTING una colección como sugirió básicamente funciona, pero surgen problemas cuando necesita informar fallas en respuesta a dicha solicitud. Dichos problemas son peores cuando ocurren fallas múltiples por causas diferentes o cuando el servidor no admite transacciones. Mi sugerencia para usted es que, si no hay un problema de rendimiento, por ejemplo, cuando el proveedor del servicio está en la LAN (no WAN) o los datos son relativamente pequeños, vale la pena enviar 100 solicitudes POST al servidor. Mantenlo simple, comienza con solicitudes separadas y si tienes un problema de rendimiento intenta optimizarlo.
Estoy trabajando en un pequeño programa de servidor cliente para recopilar pedidos. Quiero hacer esto de una manera "REST (ful)".
Lo que quiero hacer es:
Recoge todas las líneas de pedido (producto y cantidad) y envía la orden completa al servidor
Por el momento veo dos opciones para hacer esto:
- Envíe cada línea de pedido al servidor: POST qty y product_id
De hecho, no quiero hacer esto porque quiero limitar el número de solicitudes al servidor, así que la opción 2:
- Recoge todas las líneas de pedido y envíalas al servidor de inmediato.
¿Cómo debo implementar la opción 2? Un par de ideas que tengo es: Envuelva todas las líneas de pedido en un objeto JSON y envíe esto al servidor o use una matriz para publicar las líneas de pedido.
¿Es una buena idea o una buena práctica implementar la opción 2? De ser así, ¿cómo debería hacerlo?
¿Qué es una buena práctica?
En realidad, he estado luchando con esto últimamente, y esto es lo que estoy trabajando.
Si un POST que agrega múltiples recursos tiene éxito, devuelva un 200 OK (estaba considerando un 201, pero el usuario finalmente no aterriza en un recurso que se creó) junto con una página que muestra todos los recursos que se agregaron, ya sea en lectura - solo o editable. Por ejemplo, un usuario puede seleccionar y PUBLICAR múltiples imágenes a una galería usando un formulario que solo contiene una entrada de archivo. Si la solicitud POST tiene éxito en su totalidad, se le presenta al usuario un conjunto de formularios para cada representación de recursos de imágenes creada que le permite especificar más detalles sobre cada uno (nombre, descripción, etc.).
En caso de que uno o más recursos no se creen, el controlador POST aborta todo el procesamiento y agrega cada mensaje de error individual a una matriz. Luego, se devuelve un conflicto 419 y el usuario se enruta a una página de error de conflicto 419 que presenta el contenido de la matriz de error, así como un camino de regreso al formulario que se envió.
Facebook explica cómo hacerlo: https://developers.facebook.com/docs/graph-api/making-multiple-requests
Solicitudes simples por lotes
La API por lotes toma una matriz de solicitudes HTTP lógicas representadas como matrices JSON: cada solicitud tiene un método (correspondiente al método HTTP GET / PUT / POST / DELETE, etc.), una relativa_url (la parte de la URL después de graph.facebook. com), matriz de encabezados opcionales (correspondientes a encabezados HTTP) y un cuerpo opcional (para solicitudes POST y PUT). La API por lotes devuelve una matriz de respuestas HTTP lógicas representadas como matrices JSON: cada respuesta tiene un código de estado, una matriz de encabezados opcionales y un cuerpo opcional (que es una cadena codificada JSON).
No querrá enviar los encabezados HTTP para 100 líneas de pedido. No desea generar más solicitudes de las necesarias.
Envíe el pedido completo en un objeto JSON al servidor, a: servidor / orden o servidor / orden / nuevo. Devuelve algo que apunta a: server / order / order_id
Considere también usar CREATE PUT en lugar de POST
Supongo que es mejor enviar solicitudes por separado dentro de una sola conexión . Por supuesto, su servidor web debería soportarlo
Tu idea me parece válida. La implementación es una cuestión de tu preferencia. Puede usar JSON o solo parámetros para esto (matriz "order_lines []") y hacer
POST /orders
Dado que va a crear más recursos a la vez en una sola acción (orden y sus líneas), es vital validar cada uno de ellos y guardarlos solo si todos pasan la validación, es decir. deberías hacerlo en una transacción.
Creo que otra forma correcta de abordar esto sería crear otro recurso que represente su colección de recursos. Ejemplo, imagina que tenemos un punto final como /api/sheep/{id} y podemos enviar a /api/sheep para crear un recurso de ovejas.
Ahora, si queremos admitir la creación masiva, deberíamos considerar un nuevo recurso de bandada en /api/flock (o /api/<your-resource>-collection si no tiene un nombre mejor). Recuerde que los recursos no necesitan asignarse a su base de datos o modelos de aplicaciones . Este es un concepto erróneo común.
Los recursos son una representación de nivel superior, sin relación con sus datos. Operar en un recurso puede tener efectos secundarios significativos, como disparar una alerta a un usuario, actualizar otros datos relacionados, iniciar un proceso de larga duración, etc. Por ejemplo, podríamos asignar un sistema de archivos o incluso el comando unix ps como una API REST .
Creo que es seguro asumir que operar un recurso también puede significar crear otras entidades como efecto secundario.