Header Ads Widget

Ticker

6/recent/ticker-posts

 

apis-02 de primera o tercera parte

El desarrollo de una API es un ciclo de opciones interminables: ya sea que esas opciones sean la arquitectura y el diseño específicos de la API o las necesidades a largo plazo de sus usuarios , el ciclo de vida del desarrollo contiene una multitud de opciones posibles para el aspirante a desarrollador. Una de estas decisiones es si se debe desarrollar internamente o utilizar clientes externos , es decir, si se desarrolla o no una API propia o se integra con una API externa existente o contratada.

Cada una de estas opciones tiene fortalezas y debilidades significativas; en última instancia, la elección entre los dos se vuelve clara cuando se toman en consideración ciertos factores.

Fortalezas de la API de primera persona

  • Increíble control sobre el desarrollo, el diseño y la implementación.
  • Capacidad para diseñar para casos de uso y escenarios de seguridad muy específicos
  • Capacidad para supervisar todo el ciclo de vida de la API

Las API de origen son aquellas API desarrolladas internamente. A veces se las denomina API "internas" , porque se desarrollan utilizando talentos, recursos y sistemas internos. Estas API a menudo se desarrollan como parte de un protocolo o ciclo de vida de desarrollo de proyectos , incluido como un medio para respaldar una mayor integración de servicios o sistemas para otras API o clientes.

Hay una gran cantidad de puntos fuertes inherentes a la API de primera persona que hacen que este formato sea extremadamente atractivo para una empresa. En primer lugar, estas API se pueden diseñar y desarrollar dentro de los límites estrictos especificados por el desarrollador. Debido a que la API se desarrolla internamente, las necesidades específicas con respecto a los servicios integrados, los tipos de llamadas e incluso la metodología de las llamadas pueden ser dictadas por el desarrollador que la solicita.

Por ejemplo, si se desarrolla una API interna para manejar la administración de medios de una manera que procesa datos para servicios móviles mientras se mantiene la seguridad e integridad del servidor, esta API se puede desarrollar con una arquitectura muy específica diseñada para grandes cantidades de administración de datos y Solicite formatos y limitaciones para API y desarrolladores externos.

Relacionado con esta fortaleza está el hecho de que la seguridad de una API de origen puede diseñarse de manera personalizada para necesidades muy específicas y debilidades generales del sistema . Cada desarrollador de API tiene fortalezas y debilidades de seguridad altamente específicas inherentes a su estructura empresarial general; por ello, las API desarrolladas internamente se pueden estructurar en torno a estas fortalezas y debilidades de una manera que las API de terceros nunca pueden igualar. Además, los servicios que otros desarrolladores de API podrían perder, como análisis e informes , se pueden integrar desde el principio con gran efecto.

Por último, una API de primera parte interna es una excelente opción debido al simple hecho de que se pueden controlar de principio a fin: todo el ciclo de vida, desde el desarrollo hasta la implementación y la retirada, se controla fundamentalmente internamente.

Esta es una gran ventaja para los desarrolladores: el control sobre el ciclo de vida de una API es tan fundamentalmente importante y tan poderoso que realmente no se puede calcular en términos monetarios o de tiempo. Todo, desde la monetización y la promoción general en marketing, cambia durante esta fase. Permitir una gestión más integrada del ciclo de vida en lugar de optar por una esperanza generalizada de que un tercero comprenda sus necesidades específicas puede hacer que su API sea mucho más funcional y útil .

Leer más: ¿Qué factores hacen que una API sea "útil"?

Debilidades de la API de primera persona

  • El aumento de características y el aumento del alcance del proyecto son una amenaza real
  • Mayor gasto de tiempo y recursos
  • A medida que aumenta la complejidad, también lo hace el gasto, lo que reduce drásticamente la relación costo / beneficio.

Si bien hay una cantidad significativa de fortalezas inherentes a una API de origen, hay tantas debilidades que pueden hacer que el desarrollador más exigente busque soluciones de terceros. Lo primero y más importante es el alcance . Existe el viejo dicho "no se puede ver el bosque desde los árboles", y este es siempre el hecho con el desarrollo del Primer Partido.

Los desarrolladores tienden a quedarse estancados "en la maleza", y el deslizamiento de características es un problema real para un proyecto de cualquier tamaño, especialmente uno cuyo único interés mayoritario es la parte que lo desarrolla. Para combatir este simple hecho de la gestión de proyectos, es necesario establecer con mucha anticipación pautas ardientes y estrictas sobre el alcance y la intensidad, lo que complica la fase de desarrollo y requiere más niveles de gestión y supervisión.

Esto nos lleva a nuestra segunda gran advertencia: desarrollar una API internamente puede ser muy costoso . Olvidando por un momento el costo puro de desarrollar una API (que es algo que discutiremos como una de las fortalezas de las API de terceros), el hecho es que con una mayor perspectiva organizacional destinada a combatir el deslizamiento de características y promover el control sobre el ciclo de vida de la API , la organización aumento de la hinchazón y el costo de los recursos. Para revisar cada característica, supervisar cada elemento desarrollado, para asegurarse de que las piezas funcionen como se anuncia a los gerentes y funcionarios de alto rango de la empresa, es necesario que haya gerentes de intercesión, informes de proyectos, estimaciones de tiempo, etc. Esto aumenta el costo más allá del simple costo de licencia e integración de una API de terceros.

Todo esto culmina en una categoría amplia, por supuesto: el tiempo, el esfuerzo y el dinero siempre se gastarán a un ritmo mayor cuando se desarrolla internamente que externamente después de un cierto tamaño de proyecto. Si su API hace algo simple, será más económico desarrollarla internamente que licenciar una API; por el contrario, si su API hace muchas cosas con llamadas complejas, casi siempre será más costoso crear la API de nuevo en lugar de simplemente licenciarla. Esto luego se convierte en un análisis de costo / beneficio: ¿cuánto está dispuesto a pagar por el control total de su producto?

Para obtener más información sobre el análisis: Preparación de su estrategia de API previa al lanzamiento

Fortalezas de API de terceros

  • Un punto de vista diferente, creando enfoques adicionales para problemas complejos.
  • Disminución del gasto de tiempo y recursos
  • Acceso a talento, experiencia y sabiduría externos

Las API de terceros son aquellas desarrolladas fuera del usuario, es decir, si las API de origen son "internas", las API de terceros son " externas " . Estas API a menudo están diseñadas para un propósito general, por ejemplo, conectarse a un servidor y entregar contenido a sitios de redes sociales. Como tales, son mucho menos especializadas que las API de origen. Esta categoría también incluye las API que se desarrollan por contrato, es decir, aquellas API que contrata a un desarrollador o equipo de desarrollo para que las cree en su nombre.

Esta inclusión de esfuerzos subcontratados en el término "Terceros" es exclusiva del desarrollo de aplicaciones y software. Cuando se desarrollan las API, el proveedor original (en este caso, la empresa de API que contrata el trabajo) está licenciando el uso de una API desarrollada externamente en un marco exterior, independientemente de sus solicitudes de funcionalidad, lo que convierte a los desarrolladores contratados en Terceros. .

Hay una gran cantidad de puntos fuertes en tener una API de terceros, al igual que hay una variedad de puntos débiles. El primero y más importante de ellos es el hecho de que se está beneficiando directamente del conocimiento de los demás. Al desarrollar una API propia, lo hace utilizando su propio conocimiento, perspectivas y cultura corporativa. Si bien esto está bien para usos comerciales o de marca, su cultura y enfoque corporativos se limitan solo a lo que usted proporciona, lo que facilita la elección de una ruta única en lugar de opciones mejores, más baratas o más efectivas. La diversificación de su conjunto de talentos y la utilización de la experiencia de los demás puede resultar en un producto final mucho mejor que el que podría generar cualquier enfoque singular.

En segundo lugar, y algo mencionado anteriormente, la integración de una API de terceros casi siempre requiere menos tiempo, esfuerzo y dinero que desarrollar una nueva API de terceros. La integración de una solución de terceros es simple : pague una tarifa de licencia, integre en sus servicios y asegúrese de que se resuelvan los problemas de seguridad. Sin embargo, el desarrollo de una API de origen implica pagar a los empleados, crear un marco desde cero, otorgar licencias o desarrollar cualquier tecnología dependiente, pasar por el proceso de garantía de calidad y encontrar formas de monetizar. Sin embargo, estos ahorros tienen un precio, ya que la disminución del precio derivada de la subcontratación proviene necesariamente de la pérdida de control.

Todo esto tiene un costo significativo que podría mitigarse dependiendo de su propósito: si el objetivo final es desarrollar una API para luego comercializarla con otras empresas, obviamente el desarrollo de una API de primera parte tiene costos que son aceptables, pero si su objetivo final es simplemente resolver un pequeño problema o crear un pequeño portal para una tarea singular, entonces esos costos son más difíciles de justificar. Muchas de las funcionalidades que puede necesitar llamar ya existen : integración de servicios de mapas , datos fiscales , análisis de datos a largo plazo y muchos otros servicios que ya permiten la integración de API. Desarrollar estas soluciones internamente desperdiciaría recursos valiosos.

Finalmente, cuando subcontrata el desarrollo de API a un desarrollo exterior, a menudo tiene acceso a un grupo de talentos más grande y diverso del que tendría en el desarrollo interno. Si bien esto es insignificante en ciertos casos, es decir, cuando su empresa tiene una larga historia o tiene desarrolladores veteranos, el hecho es que cuando contrata desarrolladores de terceros, tiene la "elección de la basura". Mientras que el desarrollo interno depende completamente de la experiencia del desarrollador que es tan crucial para el proceso de desarrollo, la integración con desarrolladores externos le permite examinar más a fondo los equipos de desarrollo que podrían tener más experiencia, un historial probado y una mejor actualización de los elementos conceptuales.

Piénselo de esta manera: ¿preferiría utilizar su equipo local o utilizar un "equipo de ensueño" que usted mismo pueda construir? Claro, tiene un precio, pero cuando ese precio implica obtener una licencia de una empresa establecida en lugar de desarrollar algo no tan seguro utilizando su propio talento, ese precio se convierte en una variable que podría ser aceptable.

Debilidades de API de terceros

  • Es posible que las soluciones prefabricadas de terceros no se ajusten a sus requisitos específicos
  • Pérdida de control sobre el ciclo de vida de la API
  • La seguridad depende de la minuciosidad de una entidad externa

Las API de terceros tienen una serie de advertencias que las convierten en la elección incorrecta para una variedad de situaciones. Lo primero y más importante es el hecho de que, si usa una API de terceros, no está usando algo diseñado para su propósito, sino que está usando una API diseñada para consumo masivo. Esto significa que, la mayoría de las veces, su experiencia específica no se adapta a su clientela y puede requerir "revisiones" o "trucos" para realizar.

En segundo lugar, carece de control sobre el ciclo de vida de la API Si bien ciertamente puede contratar la construcción de una API para mitigar la advertencia de diseño intencional, esto agrega un costo significativo y necesariamente presenta una situación en la que está invirtiendo dinero en un proyecto con poco control o supervisión. En ese momento, el costo puede superar el beneficio de la API de terceros, lo que hace que el enfoque de la primera parte sea mucho más rentable y eficaz. Nuevamente, como análisis de costo / beneficio, cuanto más control exija sobre el proyecto, más costoso se volverá ese proyecto.

Finalmente, está poniendo la seguridad de sus sistemas directamente en manos de una entidad desconocida . Incluso si encuentra una empresa de renombre que se preocupa por sus mejores intereses, cuenta con que sus desarrolladores nunca se equivoquen, que su garantía de calidad lo aclare todo y que sus desarrolladores de alto nivel tengan la previsión de proporcionar una mayor seguridad en un entorno en constante evolución. paisaje de hackers y delincuentes . Sus necesidades de seguridad siempre deben ser privilegiadas. Los sistemas integrados que proporcionan autenticación, autorización, federación y delegación pueden descartar por completo el desarrollo de API de terceros.

Un período errante o un servicio dependiente mal implementado podrían hacer que sus sistemas sean fundamentalmente inseguros; el mejor ejemplo de esto es el infame error Heartbleed, donde un solo error en la dependencia de la criptografía OpenSSL hizo que cientos de servicios fueran vulnerables a la piratería durante la noche. Si bien esto es ciertamente un riesgo en el desarrollo de la Primera Parte, ese riesgo se puede gestionar y mitigar al principio del ciclo de desarrollo con mucho control, mientras que el desarrollo de la Tercera Parte requiere la falta de dicho control.

Escenario del mundo real n. ° 1: API de origen

Suponga que una empresa de nueva creación está desarrollando una aplicación diseñada para integrar los servicios comerciales proporcionados por su sitio web tradicional con la experiencia móvil. La aplicación presentará elementos renderizados a partir de una base de datos de elementos e imágenes almacenados en el sitio y vinculados a un sistema de informes de almacén, y proporcionará un botón de "comprar ahora" para que los usuarios soliciten una entrega inmediata.

La empresa considera sus opciones. Debido a que existe una gran cantidad de sistemas comerciales disponibles para la concesión de licencias (como 2Checkout y Stripe ) que brindan procesamiento de pago básico, la compañía considera implementar soluciones de terceros. Aunque estos sistemas pueden proporcionar la funcionalidad básica requerida, su falta de máscara de interfaz de usuario y la falta de características de seguridad específicas ponen nerviosos a los desarrolladores de esta aplicación.

En consecuencia, deciden desarrollarse internamente. Al desarrollar internamente, los desarrolladores saben que se puede lograr una mayor seguridad, protegiendo sus servidores y servicios internos. Aunque el ciclo de vida del desarrollo aumenta, en la mente de los gerentes, los beneficios del control granular del proyecto y una mayor flexibilidad superan el aumento del costo total del proyecto.

Escenario del mundo real n. ° 2: API de terceros

Imagine una nueva empresa de nueva creación, con el objetivo de aprovechar una API que localiza el restaurante más cercano de un tipo determinado y proporciona direcciones utilizando la ruta más corta desde su ubicación actual. Para los desarrolladores de aplicaciones, queda claro que el verdadero "meollo" de la aplicación - la funcionalidad de direcciones - requiere un sistema de dirección fuerte y poderoso vinculado a una base de datos de mapas.

Ya existe una solución clara: la API de Google Maps Directions proporciona exactamente esta funcionalidad y está disponible para licencia. Desarrollar una solución de origen requeriría mucho tiempo, esfuerzo y dinero, lo que sería un desperdicio absoluto considerando la funcionalidad que ofrece Google Maps a una fracción del costo.

Por supuesto, se pierde mucho control. Si el desarrollador de la aplicación quiere marcar los resultados del mapa, no puede hacerlo a través de esta API. Si el desarrollador desea cambiar la experiencia del usuario aplicando aspectos a los resultados de los mapas, puede hacerlo con las herramientas limitadas de Google, pero está fundamentalmente limitado a los aspectos de Google o los estilos de menú proporcionados por el fabricante del teléfono o del dispositivo.

Sin embargo, esta falta de control es mucho más fácil de soportar cuando se enfrenta al alto costo del desarrollo de soluciones internas y, en este caso, la startup decide implementar la API de Google Maps Directions.

Conclusión

Dado que ambas categorías tienen algunos inconvenientes y beneficios bastante importantes, ¿cuándo es el momento de usar cada una? Básicamente, la respuesta está arraigada en un propósito.

Si una empresa requiere control, First Party es la opción clara . A pesar del aumento en el costo, desarrollar una API internamente necesariamente resulta en un control total sobre el producto final.

Si se requiere simplicidad, las API de terceros son la opción clara . La integración de una solución ya existente o la contratación de cambios sutiles a un cliente existente para satisfacer sus necesidades es mucho más económica que el desarrollo completo. Por supuesto, esto viene con una disminución en el control, pero esta disminución se vuelve mucho más aceptable a medida que la solución deseada reduce la complejidad.

Es un acto de equilibrio claro, una balanza con "control" en un extremo y "simplicidad" en el otro. A medida que sus requisitos cambian entre los dos elementos, con el "control" fijado firmemente en First Party y la "simplicidad" en Third Party, su solución se vuelve clara.

Publicar un comentario

0 Comentarios