Algunos problemas además de lo que Joseph ya dijo, aunque es más esotérico:
- Falta de estabilidad, especialmente. para API web. Tal vez me han estropeado las API de Windows de Microsoft en los años 90, pero la razón por la que se llaman interfaces es porque se supone que deben ser consistentes y confiables. Facebook despreciando la mitad de su API de un año al siguiente ha causado miles de horas de desarrollador de aplicaciones en la actualización de su infraestructura solo para adaptarse a su último modelo.
- Falta de diseño de API. La mayoría de las API parecen estar desarrolladas como ventanas contenidas a un sistema subyacente; muy pocos parecen pensar en la experiencia del desarrollador al usarlo. Claro, es más fácil codificar el adaptador a la API simplemente limpiando los datos en bruto y luego pasándolos de regreso, pero para el consumidor de API, la interfaz en sí puede ser muy inconsistente. ¿Por qué se devuelven objetos de usuario en una llamada, pero la identificación de usuario es la siguiente, y me veo obligado a ejecutar llamadas getUserById () para esas identificaciones de usuario?
- Difícil de fallar con gracia. Cuando los datos son internos, es fácil mirar el código subyacente y descubrir por qué algunas llamadas funcionan y otras fallan. Sin embargo, una vez que los datos se abstraen en una API, hay una cadena de dependencia de las llamadas a la API, y si un enlace en esa cadena se rompe, probablemente no haya una buena forma para que el consumidor de la API recurra a algo razonable más allá de “el servicio no está disponible “. Por ejemplo, una llamada devuelve un grupo de identificaciones de usuario, una llamada convierte las identificaciones de usuario en objetos de usuario, una llamada busca perfiles de usuario de objetos de usuario, una llamada busca una ubicación desde una cadena (a través del perfil de usuario); cualquier falla en el camino generará un error para el usuario.