Estoy trabajando en un nuevo proyecto de aplicación para iOS, en el lado móvil. Están ocurriendo algunos cambios en la arquitectura y resulta que tendremos que confiar en una API privada personalizada que será utilizada por la aplicación que estamos creando y también por otros clientes, como un sitio web.
La API que se está diseñando sigue el estilo Rest de las operaciones URI y CRUD centradas en recursos asignadas a verbos HTTP. cosas como:
GET www.example.com/books
DELETE www.example.com/books/482094
POST www.example.com/users/6793
El problema es que este estilo a menudo lleva a la necesidad de que el cliente móvil haga muchas solicitudes para cargar una sola pantalla de aplicación o administrar una acción de IU de un solo usuario. Esto lleva a que la aplicación esté en modo de carga durante 8 segundos hasta que tenga todo lo necesario. Una aplicación lenta y que no responde.
Los clientes móviles tienen serias limitaciones cuando se trata de conectividad y, por lo tanto, idealmente, debemos seguir ese tipo de regla:
1 pantalla == 1 llamada API
1 guardar == 1 llamada API.
Hay muchas situaciones en las que esto lo lleva a un curso de colisión con los principios de diseño REST, por ejemplo:
- supongamos que su aplicación ha estado fuera de línea durante un día y necesita sincronizarse con cuatro tablas de las bases de datos de fondo y necesita una llamada como
www.example.com/sync_everything?since=2015-07-24 - Digamos que hay una pantalla en la que el usuario puede editar muchos de sus objetos, por ejemplo, marcando tareas en su lista de tareas pendientes. debería haber una manera de editar todos esos registros de tareas en una sola llamada API por lotes en lugar de una llamada API por edición.
- Digamos que hay una pantalla que mezcla información de las tablas db ORDER, SALESMEN y PRODUCT, debería obtener esos datos en una llamada en lugar de tres.
el riesgo es que podríamos terminar con la API más relajante que existe y también la aplicación móvil que no responde más inútil que existe.
La cuestión es que solo soy un nuevo contratista allí y lo que necesito es algo que me ayude a hacer esos puntos, algunos artículos de fuentes respetadas o algo así. Principales jugadores que se comprometen con el estilo REST para su cliente móvil (por ejemplo: mediante el uso de puntos finales de API agregados compuestos).
O cualquier solución para este problema general. ¡Gracias!
Respuestas:
Este es tu problema aquí mismo.
Usted ha limitado sus recursos a (supongo) los modelos en su base de datos. Como tal, lleva años cargar todos estos recursos porque su servidor no tiene un concepto de recursos que no tengan una representación en la base de datos.
Por ejemplo podría tener
que todos tienen que cargarse para obtener mi biblioteca
Esto no es un problema con el diseño RESTful, esto es realmente un antipatrón REST. No hay absolutamente nada en REST que diga que nuestros recursos deben tener un mapeo uno a uno con cualquier otra cosa en su sistema, incluidos los modelos de bases de datos.
La solución es crear más recursos que coincidan mejor con lo que desea cargar. Si tiene 5 recursos que siempre terminan juntos, cree un nuevo recurso que contenga la información de esos 5 recursos.
Lo que deberías tener es algo como esto
que solo carga todos los libros para ese usuario. "my_library" no es un modelo en su base de datos, pero es un recurso. El servidor lo crea en función de los modelos de la base de datos, pero no existe una asignación 1 a 1 y el servidor tiene flexibilidad para crear este recurso sin cambiar su modelo de base de datos.
También podrías tener
ninguno de los cuales tiene que existir como modelo en su base de datos o espacio de dominio.
Existe una idea errónea generalizada de que esto es algo incorrecto porque los marcos como Rails enseñaron a las personas a asignar recursos 1 a 1 a modelos en el espacio de dominio que se asignan nuevamente 1 a 1 con filas de base de datos. Esto no es necesario ni se recomienda.
Los recursos deben ser numerosos, baratos y ligeros . Debería ser fácil crearlos, y deberían abstraerse de su modelo de dominio. Si encuentra que necesita uno nuevo, simplemente haga uno nuevo. Si tiene problemas para hacerlo, es culpa de su marco, no es un error con REST.
Ahora la gran advertencia con eso, por supuesto, es si su marco le permite hacer esto. Los marcos como Rails y Django que han tomado el curso para mapear 1-a-1 con el fin de "ahorrarle tiempo" hacen que sea difícil hacerlo. Pero eso es un defecto con los marcos, no con el diseño RESTful.
Aquí está Jim Webber discutiendo esto con más detalle (¡incluyendo algunas excavaciones en Rails también!)
https://yow.eventer.com/yow-2011-1004/domain-driven-design-for-restful-systems-by-jim-webber-1047
fuente