2012-04-11 15 views
5

Esta es una teoría/prácticas mejor pregunta con respecto al diseño reparador y HATEOAS ...efectos secundarios sobre otros recursos

Dados los recursos:

/MyResources/(una colección de nuestros objetos de recursos)

y

/transacciones/(una colección de transacciones históricas que se han producido en el sistema)

¿Es una práctica válida para:

de POST/MyResources/

no sólo para crear un nuevo recurso en/MyResources/sino también una nueva recurso en/transacciones /?

En otras palabras, ¿puede una POST (o cualquier verbo) para una URL afectar los recursos en esa URL y en otras? ¿Hay otro enfoque? Obviamente, podríamos usar dos POST, pero eso requiere que confiemos en que el usuario mantenga un estado válido en las modificaciones de recursos múltiples.

Respuesta

4

Sí, esto está bien. Imagine otro caso donde el sistema expone un URI /myresources/latest. Cuando no hay recursos, puede devolver 404, pero cuando inicia los recursos de POST, tanto el URI canónico como el URI latest devolverán 200 OK. Hay muchos, muchos beneficios útiles para este enfoque.

Sin embargo, tenga en cuenta el almacenamiento en caché mientras diseña dichos recursos. Si PUBLICA a la colección /myresources/, por ejemplo, invalidará esa colección en cualquier caché en el camino. Sin embargo, no invalidará la colección /transactions/, y los dos índices podrían perder su sincronización. Sin embargo, pueden estar desincronizados en todo el sistema, dependiendo del gráfico de cachés entre múltiples clientes y el o los servidores de origen, pero a menudo los clientes se diseñan para esperar que esta acción a distancia sea sincrónica, y el almacenamiento en caché puede frustrar eso en casos como este.

+0

Pensamientos útiles, gracias! ¿No estaría presente el problema del almacenamiento en caché en casi cualquier API RESTful actualizable? ¿Y no se mitigaría ese problema utilizando los últimos encabezados mod? – James

+0

Sí; y sí, puede – fumanchu

1

Parece totalmente razonable para mí. No hay forma de que la persona que crea el nuevo recurso sepa si, por ejemplo, esto se implementó teniendo otra encuesta de cliente para nuevos recursos, luego se inyecta el recurso de la transacción, ¿verdad?

Por lo tanto, no hay ningún problema conceptual en ese nivel, y mucho menos el nivel "¿es razonable que el servidor cree nuevos recursos?".

Cuestiones relacionadas