Desventajas de usar APIs de terceros en nuestros proyectos

Google ya había prometido limitar su API de Google Maps, debido a que pues medio mundo de empresas, usuarios y cualquier ente humana la usaba gratis, lo que por una parte era bueno, pero para Google no tanto, ya que ofrecer un servicio donde no tiene beneficio económico alguno no es bueno (a Google le cuesta actualizar sus mapas, implementar nuevas funciones, mandar los autos para tomar fotos, etc), por lo que por fin lo hizo público.

Por eso vamos a ver algunas desventajas de usar APIs de terceros en nuestros proyectos, porque las ventajas pues creo que son obvias, o sino obvias es evidente que beneficia al no gastar tiempo creando lo que alguien más ya hizo.

Recordemos que por ejemplo, Google ya está introduciendo el límite de 25.000 mapas básicos o 2.500 mapas estilizados por día, después de ese límite tienes que empezar a pagar para poder seguir usando la API.

Bueno, para los que no saben qué es un API, Wikipedia nos da una definición sencilla:

Interfaz de programación de aplicaciones o API (del inglés Application Programming Interface) es el conjunto de funciones y procedimientos o métodos, en la programación orientada a objetos) que ofrece cierta [biblioteca (programación)|biblioteca]] para ser utilizado por otro software como una capa de abstracción. Son usadas generalmente en las bibliotecas (también denominadas comúnmente "librerías").

En otras palabras, es un conjunto de funciones ya hechas, las cuales sólo tenemos que mandar a llamar para interactuar con el contenido, o los procedimientos que nos ofrecen. Entonces, ya teniendo este concepto podemos continuar.

Desventajas de usar APIs de terceros

Las desventajas de usar APIs no son sólo que decidan ponerle precio para usarla, va mucho más allá de eso, es un poco más técnico, que puede causarle dolores de cabeza a los desarrolladores. Algunas desventajas son:

• Actualizaciones: Uno pensaría que al incluir actualizaciones se podría tener una mejor aplicación, pero pienso que no. Las actualizaciones de APIs a veces conllevan que cambian el API, además de añadir nuevas funciones, por lo que uno como desarrollador tendría que estar bien al tanto, porque en una de estas podría dejar de funcionar su aplicación.
  
• Posibles errores: No porque sea una API de un tercero nos garantiza que no tenga errores, casi cada programa, pedazo de código, o librería a la que se le agrega nuevo código está susceptible a nuevos errores, y al no tener control de la API pues no sabremos si realmente funciona adecuadamente.
  
• Dependencia: esto es muy simple, al no tener control total sobre una API estás en manos de quienes si, por lo que si algo llega a pasar con esta API, tu tendrás que hacer las debidas adaptaciones o cambios, o sea, depender de ese tercero que te ofrece la API.
  
• Tener siempre alternativas: la inestabilidad de este tipo de librerías lleva a que el desarrollador siempre tenga a la mano algunas alternativas extra para en caso de que la API cambie en cuanto a licencia de uso, como lo ha hecho ya Google,
  
• No cumple expectativas: puede que si somos unos masters dominando la API lleguemos a ver que nos queda chica, o no se ajusta a nuestras necesidades, por lo que tenemos que buscar otra API que si lo haga, o de plano empezar a desarrollar una propia. Todo se centra en que no somos los dueños de la librería, así que no podemos mejorarla aunque quisiéramos.

Lo más recomendable sería tener una API propia, pero no siempre contamos con ese tiempo, o los requisitos no funcionales necesarios para poder hacer una API de lo que sea, pero si hay que valorar estos puntos, para que no nos caigan de sorpresa algún cambio que afecte a nuestra aplicación.