CONTROL DE LECTURA API

¿Cuál de las siguientes NO es una API?. Software. Servidor. Interfaz de usuario. Aplicación móvil. Todas las opciones descritas.

¿Cuál es la principal característica de una API?. Representa un software concreto. Está construida sólo para consumo interno. Es un paquete de capacidades atractivas para el público objetivo. Obligatoriamente debe incluir interfaz programática definida. Es sólo un servidor web.

¿Qué debe preguntarse antes de desarrollar una API como producto?. ¿Quiénes son los receptores esperados?. ¿Qué colores tendrá la API?. ¿Cuánto hardware consume?. ¿Qué marca será la API?. ¿Qué flujo de información se procesará?.

¿Qué modelo de negocio utiliza Twitter con sus APIs?. APIs internas para back-end. APIs públicas que generan más tráfico que el sitio principal. APIs exclusivamente para asociados. APIs para usuarios premium. Ninguno de la opciones es correcta.

¿Cómo clasifican las APIs los desarrolladores según la demanda actual?. Por precio. Por facilidad de consumo. Por país de origen. Por lenguaje de programación. Por duración del contrato.

¿Cuál es el ejemplo dado de una API que facilita la incorporación de nuevos comerciantes?. Twitter. Amazon. Google. Facebook. LinkedIn.

¿Cuál es uno de los motivos principales por los que los desarrolladores quieren usar APIs?. Para gastar mucho dinero. Para innovar y experimentar. Para competir con otras empresas. Por obligación legal. Para evitar aprendizaje.

¿Qué significa que una API es un "producto"?. Tiene valor para el consumidor objetivo. Se vende exclusivamente en tiendas físicas. Es sólo software sin objetivos de negocio. No necesita ser atractiva. No está relacionada con desarrolladores.

¿Qué metáfora se usa para explicar el diseño y evolución de APIs?. Bicicleta. Avión. Auto de Fórmula 1. Tren. Barco.

Según el enfoque de autos de carrera, las APIs deben: Ser estáticas. Ser componentes rápidamente reemplazables. Cambiar sólo una vez al año. No tener controles. Ser complejas.

¿Qué debe ser más importante para un desarrollador al usar una API?. Facilidad de consumo. Costos en hardware. Velocidad de desarrollo de la API. Ubicación del servidor. Lenguaje de programación.

En el contexto de monetizar datos, ¿quién es típicamente el público objetivo?. Usuarios internos. Terceros y asociados. Estudiantes. Proveedores de hardware. Equipos de soporte.

En el punto de entrada "libertad para innovar", ¿quién conforma principalmente el público?. Desarrolladores internos y terceros. Clientes históricos. Público masivo. Equipos financieros. Proveedores de servicio público.

¿Para qué se usan las APIs oportunistas?. Para asegurar contrato a largo plazo. Para desarrollo rápido y aprendizaje. Solo para APIs públicas. Solo para autenticar usuarios. Para evitar reutilización.

La integración en un ecosistema híbrido debe: Ser independiente de la ubicación de la API. Mantener un perímetro de red rígido. Usar solo sistemas on-premise. Eliminar la comunicación entre sistemas. Ser limitada a aplicaciones móviles.

¿Cuál es un principio clave al mapear APIs para móviles?. Evitar crear dependencias entre aplicaciones. Tener la mayor cantidad posible de APIs diferentes. Priorizar contratos formales extensos. Crear siempre APIs empresariales estables. Rechazar el uso de APIs externas.

¿Qué cambio en la tecnología ha facilitado el manejo de múltiples APIs?. Mejores servidores físicos. Software de administración de APIs. Lenguajes de programación antiguos. Drones autónomos. Uso exclusivo de APIs REST.

¿Qué es fundamental en un entorno híbrido para el desarrollador?. Tener acceso a un catálogo sindicado de APIs relevantes. Conocer dónde se aloja físicamente cada API. Crear APIs para cada dispositivo. Limitar la cantidad de APIs a 5. Usar siempre sólo APIs propias.

¿Qué papel tienen las comunidades en la estructura API?. Sin relevancia. Son clave para la gestión y diseño de APIs. Solo para APIs internas. Restringen el acceso a APIs. Son exclusivas para usuarios externos.

¿En qué área se espera que la programación "de todo" mediante APIs crezca significativamente?. Vehículos eléctricos. Internet de las Cosas corporativa inteligente. Comida rápida. Sector inmobiliario solo. Televisión analógica.

¿Qué preguntas clave debe plantearse antes de desarrollar una API? (3 opciones). ¿Quiénes son los receptores esperados?. ¿Cómo se puede llegar a esos consumidores?. ¿Qué términos y condiciones regirán su uso?. ¿Qué lenguaje se usará en el front-end?. ¿Cuál será el precio de venta?.

¿Qué beneficios aporta el modelo de Economía API? (3 opciones). Innovación más rápida. Alcance a nuevos públicos. Exclusividad en el mercado. Facilita la integración en redes cerradas. Permite construir ecosistemas abiertos.

¿Qué características buscan los desarrolladores en una API? (3 opciones). Reutilización para acelerar entrega. Compartir para mayor agilidad. Encapsulación para poco aprendizaje. Complejidad para controlar el uso. Estabilidad perfecta sin cambios.

¿Qué construyó Amazon para potenciar su plataforma? (2 opciones). Minorista en Internet exclusivamente. Plataforma de comerciantes basada en APIs. Red social para consumidores. Sistemas bancarios para pagos internos. Un portal omnipresente para integración de terceros.

¿Qué ejemplos de APIs se derivan según su finalidad de uso? (3 opciones). APIs de pensamiento (comparten planes o intereses). APIs de acción (permiten actuar en tiempo real). APIs de video (solo streaming). APIs de sensores para el estado del sistema. APIs de control de usuarios en general.

¿Qué analogía usa el texto para describir buenas APIs? (2 opciones). Prototipos de autos de Fórmula 1. Arquitectura de software monolítica. Componentes reemplazables y analítica incorporada. Vehículos estáticos sin actualizaciones. Hardware sin interfaces.

¿Cuándo es apropiado diseñar APIs enfocadas en alta reusabilidad? (3 opciones). Para integración de asociados. Cuando la API se expone externamente como parte del modelo de negocio. Para colaboración entre equipos internos con alta dinámica. Cuando se espera un período de uso prolongado. Para colaboración entre grupos de trabajo interno.

¿Qué implica el "pensar en APIs"? (4 opciones). Evaluar qué se busca lograr para el negocio. Identificar el público objetivo. Decidir términos y condiciones para compartir APIs. Planificar solo para uso interno sin red externa. Mapear APIs con activos existentes.

¿Cuáles son características fundamentales para considerar una API como un producto exitoso? (3 opciones). Que sea atractiva para el consumidor objetivo. Que únicamente sea usada internamente y nunca expuesta. Que produzca valor tanto para desarrolladores como para consumidores. Que tenga una interfaz programática rígida y no flexible. Que se diseñe pensando en quiénes serán sus receptores y bajo qué términos será usada.

¿Qué modelos de negocio ejemplifican el poder de las APIs públicas y de asociados? (2 opciones). Twitter. Amazon. Ford. Microsoft Office. Empresas de servicios que no usan internet.

¿Qué valoran principalmente los desarrolladores a la hora de consumir APIs? (3 opciones). Facilidad de consumo. Elegancia en el código de la API. Rapidez y agilidad para usar la API. El costo de desarrollo de la API. Que la API sea fácil de reutilizar y compartir.

¿Cuál de las siguientes afirmaciones sobre APIs de acción es correcta? (3 opciones). Permiten actuar casi en tiempo real. Son ideales para notificaciones push. Son tipos de APIs que solo funcionan en offline. Pueden incluir sistemas de gestión de tareas humanas. Suelen ser evitadas para sistemas que requieren alta latencia.

¿Por qué no siempre se debe diseñar una API para ser reutilizable? (3 opciones). Porque la reutilización implica estabilidad a largo plazo. Porque algunas APIs son oportunistas y cambian rápido según necesidades específicas. Porque las APIs siempre deben ser públicas. Porque la estabilidad puede sofocar la velocidad de innovación. Porque los desarrolladores prefieren reinventar la rueda cada vez.

Las interfaces SOAP son preferidas para: (2 opciones). Integración sistema a sistema. Comunicación con IoT (Internet de las Cosas). Operaciones de TI que requieren estructura de datos precisa. Aplicaciones móviles para consumidores. Transacciones con alto volumen de mensajes no garantizados.

¿Cuáles son una visión incorrecta sobre pensar en APIs? (2 opciones). Pensar en APIs solo como canal para extender un modelo de negocio. Decidir qué APIs aportar según objetivos de negocio. Considerar los términos y condiciones para el consumo. Evaluar tanto qué APIs entregar como cuáles consumir. Pensar en APIs solo desde la perspectiva técnica sin objetivos de negocio.

En el contexto de monetizar APIs, ¿qué es necesario considerar? (3 opciones). Que el público objetivo suele ser un tercero externo. No es necesario definir términos y condiciones para usar las APIs. La calidad y confiabilidad que experimenta el usuario final. Que las APIs siempre se exponen sin pago alguno. Que puede ser necesario pagar a terceros para que usen sus APIs.

¿Cuál es el objetivo del punto de entrada API "Libertad para innovar"? (3 opciones). Descubrir rápidamente qué funciona en el mercado. Mantener APIs totalmente estables y sin cambios. Escalar rápidamente los éxitos después de probarlos. Solo proporcionar APIs predefinidas sin espacio para improvisar. Atraer principalmente desarrolladores internos, no externos.

Respecto a términos y condiciones en APIs para innovación, es correcto decir: (2 opciones). No son importantes mientras se innove rápido. Protegen la seguridad y estabilidad de los sistemas backend. Son el principal obstáculo para la innovación ágil. Suelen aplicarse más a APIs empresariales predefinidas. No aplican para APIs usadas solo internamente.

¿Qué caracteriza a las APIs oportunistas? (3 opciones). Son rápidas y baratas de desarrollar. Se espera que duren muchos años sin cambiar. Pueden descartarse rápidamente si no resultan útiles. Se planean con mucha anticipación dentro de la organización. Se crean para responder a necesidades inmediatas y cambiantes.

En la monetización de datos vía APIs, ¿cuál es la forma correcta de implementación? (2 opciones). Curar los datos y funciones con foco en calidad y confiabilidad. Priorizar siempre reducir costos sin pensar en experiencia usuario. Experimentar sin necesidad de un producto estable. Crear APIs empresariales estables para un uso prolongado por terceros. Ignorar a los usuarios internos en la estrategia.

¿Qué importancia tiene el catálogo de APIs para los desarrolladores? (3 opciones). Debe mostrar todas las APIs disponibles sin excepción. Debe limitarse a mostrar solo las APIs relevantes para cada desarrollador. Facilita encontrar y consumir APIs de terceros sin salir del entorno propio. Solo viene bien cuando no hay muchas APIs en la organización. Es una herramienta para simplificar la experiencia y mejorar la productividad.

¿Qué tipo de APIs son preferidas para IoT según el documento?. SOAP. MQTT. REST. XML-RPC. FTP.

¿Qué papel juega la experimentación en el desarrollo de APIs según el texto? (3 opciones). Es imprescindible para acelerar la innovación. No debe afectar la estabilidad y seguridad. Permite probar rápidamente ideas y aprender de los resultados. Solo puede hacerse después de lanzar APIs robustas y definidas. Es irrelevante en grandes empresas con muchos activos legacy.

¿Cuál es una forma de consumir APIs de terceros recomendada? (2 opciones). Consumir directamente de los portales públicos sin intermediarios. Adecuar o curar APIs públicas para simplificar su versión interna. Ignorar las APIs sociales y centrarse solo en APIs internas. Limitar el consumo a APIs API monetizadas. Incorporar estas APIs al catálogo interno para facilitar su descubrimiento.

En el contexto de "Programar todo", ¿qué se menciona como foco principal? (2 opciones). La integración de personas, software y máquinas para experiencias inteligentes. Solo la creación de apps móviles para consumo masivo. La manufactura, logística y atención en salud como sectores clave. La exclusión de la Internet de las Cosas en el mundo corporativo. La programación únicamente de software tradicional.