#IBM Developer
Si todas sus API están estrechamente relacionadas, son relevantes como grupo para sus diversos consumidores objetivo y se gestionan como un grupo; es posible que desee crear un único producto API que incluya todas sus API. Este es un enfoque común.
Sin embargo, si existe una agrupación natural de API (por línea de producto, audiencia, propósito comercial, etc.), cree productos de API en ese sentido.
En general, al ofrecer menos productos de API a un consumidor determinado, le facilita comprender y utilizar sus API. Por otro lado, necesariamente está uniendo el ciclo de vida de lanzamiento de sus API cuando las agrupa en un producto.
Intenta evitar incluir la misma API en varios productos. Si terminas incluyendo diferentes versiones de una API en varios productos, asegúrate de que la ruta de tu API refleje el número de versión. Esto permite que los consumidores que están suscritos a múltiples versiones de API sean proscriptivos sobre qué versión pretenden usar. (Cuando un consumidor está suscrito a una única versión de API, API Connect enrutará la solicitud de manera adecuada en función de la información de suscripción).
Fuente
- https://developer.ibm.com/apiconnect/2017/06/30/organizing-apis/
- https://www.ibm.com/support/knowledgecenter/es/SSMNED_5.0.0/com.ibm.apic.overview.doc/overview_apimgmt_about.html
- https://www.ibm.com/support/knowledgecenter/es/SSFS6T/com.ibm.apic.overview.doc/capim_overview_orgsprodsplansapis.html
#Roberto (Feedback)
En realidad es cómo lo quieras presentar a tus consumidores.
Si hace sentido tener APIs repetidas en diferentes productos porque los vas a ofrecer a diferentes consumidores no es problema.
El problema va por el lado de administración y gobierno, por que terminas con diferentes versiones desplegadas en diferentes productos
Lo normal es que gane la gobernabilidad y tengas pocos productos con APIs diferentes.