Tengo una plataforma de rieles que mantengo. Tiene muchas aplicaciones web diferentes creadas sobre él. Sin embargo, ahora un cliente solicita una API para poder mantener a los usuarios en su sitio, pero aprovechar algunas de las tareas automatizadas que tenemos.
La plataforma se utiliza para crear aplicaciones de seguros y permite su compra en línea, además de proporcionar formas de descargar documentación relacionada con su póliza.
Entonces mi pregunta al construir la API es esta:
Cuando tengo que hacer un montón de cosas, como validate, crear una user, user profiley policy, más o menos al mismo tiempo. ¿Debo hacer 4 llamadas API separadas y hacer que el cliente cree 4 llamadas de su lado? ¿O debería tener una llamada que exceptúe muchos parámetros, que valide al cliente y cree las 3 cosas al mismo tiempo, simplificando las cosas para el cliente?
El cliente, en este caso, obtiene toda la información requerida al mismo tiempo, por lo que no es que haya un flujo natural en su aplicación donde se detenga y pueda hacer una llamada API a mi plataforma.
Después de haber estado en el lado del cliente usando muchas API antes, mi objetivo es hacerlo lo más simple posible para el cliente y hacer que solo hagan una llamada. Sin embargo, esto está dando lugar a bastante grande functionsen la API, de la que tampoco soy fanático.
¿Cómo sugieres que aborde esto?
Como nota, no tengo mucha confianza en la capacidad de los clientes para implementar una API complicada de su lado.
createUserProfilesin él tambiéncreateUser? Si no, entonces no lo expongas.Creo que lo estás mirando de manera incorrecta. No te preocupes por lo grande | llamadas pequeñas o muchas | pocas llamadas
Piense en los objetos de negocio y las acciones que se pueden realizar con | para | contra esos objetos.
Tienes:
Por lo tanto, debe crear llamadas API alrededor de esos objetos.
La idea es crear operaciones atómicas o casi atómicas basadas en los objetos comerciales y sus acciones. Esto simplificará el diseño y la codificación: llamadas que hacen lo que debe hacer el objeto comercial que coincide con el modelo mental o las expectativas de los programadores. Cuando los programadores o arquitectos discuten los requisitos con los analistas de negocios, todos pueden usar la misma terminología y flujo general de operaciones.
El problema con las llamadas de tipo todo en uno más grandes es el riesgo de efectos secundarios. Si Policy.Create también genera un usuario y desencadena alguna otra acción, eso rompería las expectativas de los programadores. Del mismo modo, muchas llamadas pequeñas obligan al programador a recordar llamar a A y luego a B y luego a C para realizar una operación comercial "única".
Y cómo nombra las llamadas se basará en lo que admitirán Rails y sus servicios web de soporte.
Para ser más prescriptivo, esto creará algunas llamadas que toman una serie de parámetros y pueden tener múltiples llamadas en el back-end que están ocultas para el cliente. También terminará con algunas llamadas bastante rápidas / simples donde la API es poco más que un contenedor de la rutina subyacente.
fuente
Creo que su intuición es correcta: simplifique la API para los consumidores. Hasta cierto punto, esta es la filosofía detrás de los contratos impulsados por el consumidor .
Más específicamente, la API debería exponer casos de uso empresarial adecuados. Considere el dominio comercial en cuestión: ¿existe realmente la necesidad de esas funciones de bajo nivel? ¿Cuál es el inconveniente de encapsularlos? Las funciones grandes en la API no son un problema en sí mismas. Lo que sería un problema es si una función grande secuencia operaciones que pueden necesitar ser particionadas para permitir la intervención del consumidor.
fuente
Personalmente, me gustan las API que:
fuente