Clase 7 - API's

Bueno, hola a todos y todas, ¿cómo están? Bienvenidos a esta nueva clase, clase número siete. La clase de hoy va a ser sobre APIs. Así que bueno, espero que les guste. Antes de de empezar quería recordarles algo que que venimos conversando en las últimas clases y es que no se olviden de completar el formulario de de Google porque, bueno, a través de ese formulario es que estamos eh tomando asistencia en este caso de las clases asincrónicas. Así que bueno, recuerden que eso es muy importante para mantener la continuidad dentro del del curso. Eh, así que bueno, espero que que los puedan completar. Eh, y como siempre les digo, cualquier duda, consulta que tengan, eh, me pueden escribir eh, ya sea a través del del grupo de WhatsApp que tenemos por mail, eh, a través del campus. Este, yo voy a estar este ahí atento para intentar solucionar cualquier este duda o o inquietud que surja. Así que bueno, sin más preámbulos, vamos a a empezar por esta parte, por el primer bloque de de la clase de hoy. Eh, sepan disculparme que hoy no pongo la cámara, pero eh evidentemente no no está funcionando acá en la computadora que siempre utilizo. Así que bueno, de todas maneras no se van a perder de mucho si no me ven, pero sepan que no por ese motivo no la estoy poniendo, así que va a ser hoy más este una especie de de podcast en todo caso. Así que bueno, de todas maneras como siempre eh acá les dejo una diapositiva, un slide, un una PPT para que puedan para que podamos ir siguiendo un poco lo que vamos lo que vamos conversando, aunque sea con una distancia. en este caso. Así que bueno, vamos a empezar entonces por eh por el principio eh para tratar de entender un poco eh qué es una API. No sé si ustedes han usado alguna vez eh APIs si saben lo que son, están familiarizados esta con esta idea. Pero bueno, básicamente API es una una sigla, ¿sí? a piez una sigla que eh significa application programming interface. Básicamente se suele traducir como interfaz de programación de aplicaciones. Suena algo técnico quizás, pero bueno, la idea es bastante bastante concreta, bastante simple, ¿eh? Y es la siguiente, ¿no? Una API es la forma un sistema eh le pide algo a otro sistema, ¿sí? y básicamente recibe este una respuesta, por supuesto, ¿no? Eh, básicamente es un mecanismo para que los programas se comuniquen entre sí. Sí, esa es la idea, la idea central. ¿Sí? Entonces, eh, en este caso, la palabra eh interfaz si no se refiere como por ahí nosotros pensamos este a una a una pantalla, ¿no? A un botón, a una ventana. Básicamente se refiere a un punto de contacto, ¿sí? Es decir, es esa parte de un sistema que queda disponible, ¿sí?, para que otro sistema pueda interactuar eh con él, ¿no? O sea, cuando una aplicación necesita una función que no tiene internamente, muchas veces eh no la construye a esa función desde cero. Lo que hace es pedirla a otro servicio. ¿Y cómo lo hace? Bueno, usando una una API, ¿sí? Este, básicamente una API funciona como una una puerta, si se quiere, ¿no? Una puerta. este que tiene cierto orden, ¿no? Este, pero bueno, una puerta de acceso a una capacidad externa. Sí, como les decía, como les decía recién. Eh, y bueno, obviamente esta capacidad puede ser muy distinta según el según el caso, ¿no? Es decir, se puede consultar el clima, se puede traducir un texto, eh procesar un pago, ¿sí? Como usamos actualmente múltiples aplicaciones, ¿no? Generar una imagen, hacer un prompt, etcétera. Pero bueno, la lógica eh básicamente es siempre la misma, ¿sí? Es decir, una aplicación necesita algo, eh, eso que necesita lo pide a través de una API y usa la respuesta que recibe. Sí, usa la respuesta que recibe. Entonces, acá una primera idea, este central para entender y es que la API no es un modelo como los que nosotros venimos trabajando, ¿sí? Eh, no es tampoco la aplicación del usuario y tampoco es el resultado final, no tiene que ver con eso. Y la API es esto es importante, es el canal, es el canal formal, ¿sí?, que conecta una cosa con otra, ¿sí? Entonces, eh cuando una app, ¿no? Una aplicación, por ejemplo, utiliza inteligencia artificial, muchas veces no significa que tenga esa app eh un modelo de inteligencia artificial propio o integrado. Significa en muchos casos que lo que está haciendo es conectándose a un servicio externo que sí lo tiene. Sí. Y en ese y eso es ese vínculo lo hace a través de una API. Sí. Eh, les pongo un ejemplo simple, ¿no? Imagínense una plataforma X puede ser una plataforma eh educativa, ¿sí? Este, Coderhouse, por ejemplo, que ofrece cursos relacionados con el tema que nosotros estamos trabajando ahora, ¿no? Entonces este imagínense que en esa plataforma hay un botón que dice explicar este texto de manera más simple. Sí. Bueno, cuando el estudiante o el que está haciendo el curso hace clic ahí, lo que posiblemente esté pasando es lo siguiente. La plataforma toma ese texto, lo envía a un servicio externo de inteligencia artificial usando una API, ¿sí? Y recibe una versión, por supuesto, mucho más clara, ¿no? Este, del pedido, digamos, ¿no? Y muestra eso en la pantalla. Entonces, desde el lado del usuario, desde la experiencia del usuario, ¿sí? Eh, parece que la plataforma entiende el texto. Sí, incluso desde lo técnico, este, pareciera que que es así, pero en realidad lo que está haciendo es consumir una API. ¿Sí? Entonces, eh cuando pasa esto, ¿sí? Cuando en informática, digamos, cuando un sistema ofrece una función para que otros la utilicen, ¿sí? hablamos de un servicio. Sí, un servicio. Y la API entonces es este esa forma concreta en que ese servicio se vuelve utilizable. No sé si me siguen hasta acá, ¿no? Entonces, si alguien ofrece una app inteligencia artificial, lo que está ofreciendo en realidad es un acceso a un servicio de inteligencia artificial. Eh, hay un una cuestión importante que que que hay que destacar acá, ¿no? Y es la relación justamente entre eh el cliente y el servidor. El cliente es el sistema que hace el pedido. El sistema que hace el pedido es el cliente y el servidor va a ser el sistema que lo recibe, que lo procesa y que después nos va a dar la respuesta, ¿no? Entonces, cuando una aplicación envía un texto, por ejemplo, ¿no? viendo el ejemplo que les decía recién a una API, para resumirlo, esa app, esa aplicación está actuando como un cliente, se entiende y el sistema remoto que procesa ese texto actúa como si fuese un eh servidor. Sí. Eh, les digo esto porque normalmente hay una confusión bastante común y es que cliente no significa necesariamente una persona, ¿no? Sino en este caso es un software y servidor no es eh una máquina física, ¿no? Sino este el lado del sistema preparado para responder esos pedidos, ¿no? Entonces, eh retomando un poquito lo que les decía antes, la API es esa interfaz que nos que permite, ¿no?, que un programa use funciones o recursos de otro programa. mediante un intercambio de solicitudes y de respuestas, ¿no? Este, esto es eh esencial que lo tengamos presente eh para lo que va a para lo que vamos ir viendo a lo largo de de la clase, ¿no? Entonces, a mí me gusta esta idea de pensar la API como puente, ¿no? Como puente entre sistemas, ¿no? E por qué usamos esta metáfora? Bueno, si se dan cuenta, si se ponen a pensar un momento, un puente no digamos no mezcla dos dos territorios, eh, tampoco los los convierte en un solo territorio, sino que lo que hace en todo caso es permitir, ¿no?, un paso eh relativamente ordenado entre ambos territorios, ¿no? Bueno, una API eh es algo parecido, ¿no? Es algo parecido. La aplicación que la usa no necesita conocer toda la complejidad interna del sistema, ¿no?, que está del otro lado. Lo que necesita es saber cómo acceder correctamente a esas funciones y nada más, ¿no? Entonces, la API funciona en este sentido como este un acuerdo, si se quiere, ¿no?, de comunicación. Este, ¿por qué por qué les digo esto de un acuerdo? Bueno, porque no se pueden mandar los datos de cualquier manera. Hay ciertas reglas, ¿no? Este, hay ciertas reglas de a dónde enviar el pedido de información. ¿Qué información se puede incluir? ¿En qué formato este y cómo se lee la respuesta? Esto lo vamos a ver más al final de la clase cuando veamos un poco Jason. ¿Sí? Entonces, esto es importante porque eh digamos gracias a estos distintos sistemas es que pueden trabajar juntos, ¿no? Este aunque hayan sido desarrollados por eh por equipos diferentes, por tecnologías diferentes en contextos distintos, etcétera, ¿no? Eh, y de alguna manera también es lo que vuelve tan importante, digamos, a una API, ¿no? Este, porque permite algo que comúnmente se conoce como interoperabilidad, ¿no? Es decir, sistemas diferentes pueden colaborar sin necesidad de ser iguales, ¿no? Este, entonces, bueno, esto es algo muy importante. Pongo otro ejemplo, una aplicación, ¿no? Para atención al cliente, ¿no? Que quiere, volviendo un poquito al ejemplo también anterior, resumir mensajes, por ejemplo, ¿no? Clasificar los reclamos eh y sugerir respuestas a partir de esos reclamos. por ejemplo, lo usa Mercadool Libre hoy en día, ¿no? Bueno, en lugar de construir toda esa inteligencia desde cero, se puede integrar con un servicio externo. ¿Se entiende la idea? Entonces, eh la aplicación envía los mensajes que va recibiendo a través de una API, recibe las respuestas y las incorpora en flujo de de trabajo, ¿no? Entonces, bueno, eso va a representar una mejora para el usuario, ¿no? Por debajo va a haber este sistemas hablando entre sí, este, mediante una API, comunicándose a través de una API, ¿no? Entonces, eh lo que permite finalmente la API es eh acceder a una capacidad, ¿no? Este, sin tener que ver toda la maquinaria, toda la infraestructura interna, ¿no? Eh, si por ejemplo utilizo una API de inteligencia artificial, no necesito saber cómo se entrenó todo ese modelo, ¿no? En qué servidores corre. Lo que sí necesito saber es qué información pedir o qué dato pedir y cómo interpretar la respuesta que voy a a recibir, ¿no? Por supuesto, eso no quiere decir que lo interno, ¿no? Que todo el funcionamiento de este interno no importe, ¿no? Por supuesto que no importa y mucho, eh, sobre todo, bueno, para entender eh no solo los límites que tiene esa interacción, sino también los costos que puede tener asociados, ¿no? Eh, los sesgos que puede tener. Pero bueno, desde el punto de vista de la integración, las APIs simplifican mucho toda esa complejidad, ¿no? Por eso tantas aplicaciones hoy en día pueden usar inteligencia artificial. Vieron que hoy hay un montón de aplicaciones que usan inteligencia artificial, eh, y toda esa inteligencia artificial que usan la usan sin necesariamente haberla creado ni tener este modelos propios ni mucho menos, ¿no? Eh, pero bueno, es importante eh tener esta distinción en en mente. Sí. Em, bien. Bueno, acá me estaba adelantando yo un poco a lo que les iba a decir eh recién. Eh, hoy en día cuando una aplicación incorpora inteligencia artificial, muchas veces lo que hace sí es eh conectarse con un modelo eh a través de una API. ¿Sí? Entonces, eh esto es importante porque toda la expansión que tenemos actualmente de la inteligencia artificial eh no depende solamente de que existan buenos modelos, no como los que venimos viendo en las clases anteriores, sino de que esos modelos se puedan usar desde otros sistemas, ¿no? Eh, y que el acceso sea práctico, que sea estable, que sea seguro. ¿Se entiende? Entonces, eh en este contexto, ¿no? Por supuesto, todo esto es posible gracias a las APIs, ¿no? Pero es muy interesante pensar entonces la inteligencia artificial como un servicio remoto. Sí, o sea, las aplicaciones no tienen el modelo de inteligencia artificial internalizado, ¿no? Envían una solicitud a un sistema externo, ¿no? esperan la respuesta y usan y la usan en la interfaz que tienen. Sí, por eso es que muchas veces este funciones que parecen nativas de esa aplicación en realidad son llamadas a una API. Y esto se los digo también para que ustedes si el día de mañana se van a dedicar a la programación o ya están programando, sepan que eh utilizar APIs es un recurso importantísimo, importantísimo a la hora de de programar, porque les va a permitir interactuar con un montón de herramientas que ustedes no tienen por qué saber construir, a menos que estudien específicamente programación, por ejemplo. Pero bueno, pueden aprovechar herramientas que ya existen y que son muy útiles para incorporarlas dentro de la infraestructura de sus propios proyectos. Sí. Eh, les digo un ejemplo también este eh relativamente reciente, ¿no? Eh, una una aplicación, por ejemplo, de recursos humanos que recibe currículums y se encarga de este resumirlos o analizarlos. Sí, puede ser también este una plataforma de ventas, como decíamos antes, que clasifica mensajes, una aplicación educativa, ¿no?, que reformula algún contenido o por ejemplo puede ser un editor de código, ¿no?, que hay un montón hoy en día que nos sugiere ciertas funciones, por ejemplo, ¿no? Entonces, en todos los casos, la lógica es similar. La aplicación, ¿sí? Una aplicación X envía una entrada y recibe una salida. Sí. y muestra el resultado. Sí. Eh, básicamente es eso. Y el puente, ¿sí? Este, entre todo este proceso de interacción es la API, ¿no? Eh, el macher learning, si alguno está familiarizado con el tema a este momento, ¿no? Se lo llama inferencia. Se lo llama inferencia, ¿no? Básicamente esto es cuando un modelo recibe una entrada y produce una salida. Entonces, cuando una app llama a una API de inteligencia artificial, ¿sí? Muchas veces lo que está haciendo es solicitar una inferencia. Sí, esto para verles algún concepto un poquito más eh técnico, ¿no? Entonces, detrás de una acción que puede parecer simple, ¿no? Hay toda una secuencia técnica atrás y esto, por supuesto, para el usuario puede ser invisible, prácticamente invisible. Entonces, eh esto es importante para entender, ¿no?, cómo funciona la inteligencia artificial eh en aplicaciones reales, ¿no? Eh, bien, espérenme que no me quiero adelantar a la próxima este diapositiva, así vamos parte por parte. A ver, bueno, acá les puse algunos ejemplos, ¿no?, eh, de cómo de cómo funciona, ¿no? Este, algunos ejemplos concretos, ¿no? Una app del clima, ¿no? Que obtiene datos, por ejemplo, a través de un servicio meteorológico. Sí. Este, obviamente í hay una una API conectándose, ¿sí? con este los datos del servicio meteorológico y trayendo esa información a la aplicación del clima que estamos utilizando. ¿Sí? Fíjense que abajo puse un dibujito, ¿no?, de cómo es la secuencia entre las apps, la API, ¿sí? Y cómo es el camino hacia el usuario final, ¿no? Lo mismo podemos este llevar al ámbito de de las aplicaciones de traducción, de pagos, de mapas. Bueno, prácticamente cualquier aplicación hoy en día. Sí. eh de alguna manera utiliza alguna este API para eh para eh traer información. Sí, esto bueno, cada vez es es más generalizado, pero bueno, se utiliza ya hace muchísimo tiempo. Entonces es un una práctica muy muy común. Sí, muy común. Bueno, hasta acá un poco un pano general, ¿no? Por lo que es este una API. Sí. Ahora bien, vamos a a trabajar sobre esta idea de los end points. Sí vimos recién este en estas cuatro diapositivas anteriores, ¿no? Que es una API, cuál es su función, este, para qué se utiliza, sí, pero bueno, podríamos preguntarnos, ¿no? Si la eh API es la puerta de acceso. Sí. Bueno, este podríamos preguntarnos eh por dónde se entra exactamente, ¿no? Este, y ahí aparece este concepto que les traigo acá, que es el concepto de end. Esta palabra end point puede traducirse si se quiere, ¿no? Como punto de acceso, punto de acceso, punto final, ¿no? En la práctica, básicamente un endp. Ven que yo ahí puse donde está el loguito de de del mapa que dice apl.servicio.com. Bueno, básicamente sí eh es este una dirección concreta dentro de una API, ¿sí? A la que le enviamos una solicitud para hacer algo específico. ¿Se acuerdan que antes decíamos, no? Que hay una comunicación con la API, ¿no? Bueno, entonces, ¿cómo nos comunicamos específicamente? Bueno, con una dirección concreta. Con una dirección concreta, ¿sí? Eh, es un lugar puntual dentro de esa API. Si ven que dice P1/hat/ este complections. Okay, esto es importante porque una API no es este muchas veces una cosa, una única cosa definida, ¿no? Sino que la API también es un conjunto organizado de accesos y cada uno tiene una función distinta. Sí. Este puede haber un endpo para generar texto, otro para embedings, otro para imágenes, otro para listar modelos, otro para hacer una consulta sobre alguna operación, etcétera, ¿no? Entonces, pasándolo un poco en limpio lo que decíamos recién, una API es el sistema general de comunicación, ¿sí? General. Y los end points son los puntos específicos en donde donde ocurre cada una de esas acciones. Entonces, eh si se quiere para poner una imagen mental este gráfica, eh imagínense que un edificio completo, ¿sí? Un edificio sí entero es una API, ¿sí? Y los end points son las oficinas que están adentro de ese edificio o las o los departamentos que están en ese edificio. Sí. O sea, el edificio es uno solo, pero adentro hay diferentes lugares en los que se pueden hacer diferentes trámites, en los que se pueden hacer diferentes cosas, en los que hay diferentes familias viviendo. ¿Sí? Entonces, con las APIs pasa lo mismo. Cada operación, ¿sí? Que se hace tiene su propia dirección, su propio piso, su propia oficina, su propio cuarto. ¿Sí? Este, entonces les voy a hacer una aclaración porque por ahí se puede llegar a prestar a confusión porque ustedes por ahí ven esta dirección ahí de apl.com y dicen, "Eso se parece mucho a una URL, ¿no? Bueno, no es lo mismo API que URL que Endpoint. Sí, la URL es la dirección completa, ¿sí?, de una página web. Sí, puede ser la página web de esa misma aplicación, no importa. Sí, pero dentro de esa URL sí, una parte corresponde al endpoint. ¿Sí? Entonces, cuando hablamos de endpo a lo que nos referimos es al a ese punto funcional, ¿sí?, que eh adentro de una API, adentro de ese edificio que les decía recién, activa una determinada acción. ¿Sí? Por ejemplo, una API de inteligencia artificial, un edificio de inteligencia artificial puede tener un un endpo un departamento, una oficina, una casa ahí adentro de ese edificio para generar un texto y adentro del mismo edificio otro para generar imágenes. ¿Se entiende? son endpints distintos, aunque aunque pertenecen, perdón, al mismo edificio, al mismo servicio. Eh, y esto es importante porque los endo points entonces eh no solamente sirven para recibir información, ¿sí? sino que también nos ayudan a definir qué tipo de operación queremos hacer, queremos realizar, ¿no? Eh, porque no es lo mismo pedir una respuesta, digamos, este, conversacional, ¿no? Que pedir un embeding, por ejemplo, ¿no? No es lo mismo transcribir un audio que generar una imagen, como vimos anteriormente. Entonces, cada acción tiene su propio punto de entrada porque eh utiliza o maneja elementos distintos, ¿no? Entonces, un endpoint, además de ser una dirección en términos técnicos, ¿sí? Es también una forma de organización conceptual. ¿Sí se entiende la idea? O sea, este diferentes acciones van a estar asociadas a endpspoints este diferentes. ¿Sí? Eh, bien. Entonces, como decíamos antes, lo podemos pensar también como si fuese un mapa en este dibujito que yo les puse, ¿no? Cada endp estructura mayor, ¿sí? No está aislado. Si lo quieren seguir pensando como el edificio, lo pueden seguir pensando. Forma parte, ¿sí? de una red de unidades, de lugares de oficinas, de casas, etcétera, todas en un mismo eh en una misma estructura. Sí. Eh, pero bueno, básicamente eh digamos todas tienen, o sea, el el propósito sí está claro, pero está dentro de un conjunto que organizado, ¿no? Es decir, eh una API, ¿no? Eh, expone o provee, digamos, recursos y operaciones, pero de manera ordenada. Sí, ordenada. ¿Por qué digo hago hincapié en en esta palabra en ordenada? Bueno, porque hay una idea importante que es la idea de ruta. Por eso les puse el mapita en este caso, ¿no? Porque la ruta es el camino que sigue una solicitud, un pedido dentro de la API hasta llegar a la acción correcta. Es como la persona que va, toma el ascensor, sube, va, va hasta un departamento, no era ese al que tenía que ir, baja, va otro. Esa ruta. Sí. Eh, en una API la ruta suele expresar de alguna manera la lógica del servicio. Nos dice si estamos generando un contenido, consultando algún modelo en particular, si estamos recuperando algún dato, estamos ejecutando alguna tarea eh específica, ¿se entiende? Entonces, eh básicamente usar una API, usar una API eh no es solamente saber qué qué es lo que contiene, ¿no? Sino también de alguna manera es conocer ese mapa de todas las Entonces si uno es un desarrollador, uno necesita saber qué end corresponde a cada objetivo. Sí, si yo soy un desarrollador y el edificio mío de X API, no Tal API, adentro tiene una oficina que es para diseño, otra oficina que es para producción de texto, etcétera. Yo necesito saber qué departamento, qué oficina es la que hace cada cosa. Sí. Eh, por eso es que esto es algo de sentido común, pero enviar datos, ¿sí? Un pedido al lugar correcto es tan importante como los datos en sí mismos. Sí se entiende. Es muy importante esto. Entonces, eh la comunicación técnica en este caso eh ocurre dentro de una estructura que está muy bien definida. Sí. Eh, básicamente digamos una API de inteligencia artificial, por ejemplo, que permite generar texto, analizar imágenes, etcétera. Bueno, si todos enviara al mismo punto, el sistema sería un caos, sería confuso. Por eso cada capacidad suele tener su propia ruta, ¿no? Y eso hace, obviamente, que una API sea eh más clara, predecible, ¿no? Que sea fácil de mantener también, porque a medida que un servicio crece, esta organización se vuelve muy importante. Imagínense que a diferencia de lo que pasa en la vida real, este edificio podría llegar a tener, no les digo infinitos pisos, pero podemos seguir construyendo hacia arriba, ¿no? O hacia los costados. Entonces es muy importante tener muy bien documentado todo esto, ¿no? Eh, y bueno, gran parte de esa claridad depende de cómo estén pensados esos end points, ¿no? Por eso lo la documentación, reitero, es muy muy importante, es una muy buena práctica, ¿no? Porque la documentación va a mostrar qué ends existen, qué hace cada uno, qué datos eh digamos espera recibir y a su vez y qué datos puede devolver, ¿no? Entonces, bueno, usar una API básicamente no es solamente tener acceso, ¿no? Sino es saber navegar en esa estructura, ¿no? Esa estructura, este, por supuesto que no es una estructura arbitraria. Eh, esperen que me salió un cartelito ahí. no es una este estructura arbitraria, ¿no? Sino que detrás de de cada end point hay decisiones, ¿sí? de diseño, etcétera, eh que buscan específicamente separar funciones y evitar esas ambigüedades, ¿no? Entonces, para creo que está bastante clara la la dinámica del del edificio que les decía recién, ¿no? Pero básicamente eh una API bien diseñada no es este un túnel, ¿no? único, este, sino es toda una red de caminos, ¿no? donde cada uno de los ends cumple este su rol, ¿no? Cada uno de los ends cumple un rol dentro de esa de esa ruta. Imagínense eh un servicio de inteligencia artificial con eh varias capacidades, ¿no? Eh, como les decía recién, puede haber un endpoint que genera texto, otro para imágenes, otro para audio, otro para embedings, etcétera. desde afuera parece que fuese la misma inteligencia artificial, ¿sí? Pero técnicamente van a ser operaciones distintas, ¿no? Eh, si una app quiere enviar un prompt, un modelo, eh, va a usar un endpoint de texto, por ejemplo, ¿no? Y si quiere convertir ese texto en vectores numéricos, va a usar otro. ¿Sí? Entonces, eh yo usé varias veces acá la palabra embeding, ¿no? Bueno, un embeding es una representación numérica. numérica de un contenido eh que permite de alguna manera comparar ciertas similitudes o buscar información eh relacionada. ¿Sí? Entonces, aunque para el usuario usar inteligencia artificial parezca una sola cosa, detrás hay tareas que son bastante este diferentes, ¿no? Eh, por eso yo les pone el ejemplo, por ejemplo, de una plataforma educativa, ¿no? digamos, una plataforma educativa por ahí quiere responder preguntas, busca contenidos parecidos, genera imágenes, ¿sí? Toda la plataforma puede usar el mismo proveedor de inteligencia artificial, pero distintos endpints según la tarea este que se le esté solicitando. Sí, la API siempre va a ser la misma, pero el trabajo que se reparte, ¿no? Entre los distintos puntos de acceso, este ahí sí va a ser diferente, ¿no? Entonces, bueno, los endints, además de organizar toda esa infraestructura, también organizan la forma en la que pensamos el problema, ¿no? Porque básicamente nos obligan a distinguir las tareas, ¿no? Y a entender que usar inteligencia artificial también puede significar cosas bastante eh distintas, ¿no? Por eso integrar una app de inteligencia artificial no es solamente decir vamos a usar inteligencia artificial, no, es principalmente preguntarnos para qué exactamente. Bien. Mm. Bueno, obviamente elegir el endpoint correcto eh va a ser una parte central de de la integración. Sí, yo acá les puse unos ejemplos de depoints en servicios de inteligencia artificial, diferentes servicios, Open AI, Antropic, Google AI, ¿no? Un endp ejemplo, ¿no? ¿Cuál es el método? Que ahora los vamos a ver en un par de diapositivas. Vamos a ver el método se utiliza, ¿no? Para qué sirven, ¿no? Cada uno de estos ends y un ejemplo concreto de de uso. Sí. Em, bien, muy bien. Bueno, vamos a ver ahora entonces eh un poquito eh request y response. Sí, hasta ahora dijimos que una, digamos, dijimos este de manera bastante simple que es una API, que son los end points, pero nos tendríamos que enfocar ahora en eh de alguna manera el corazón del intercambio, ¿sí? Del intercambio. Fíjense que yo puse un dibujito arriba, ¿no? Cliente API, ¿no? Y en el medio está eh el request. Sí. Bueno, dijimos que los sistemas se comunican, ¿no? Pero bueno, todavía no vimos cómo ocurre esa ira y vuelta en la práctica, ¿no? Por supuesto, la idea no es ser técnicos extremadamente acá, aunque les puse algunos ejemplos prácticos este con eh algunos códigos acá para los que quieran profundizar un poquito más, ¿no? Pero bueno, dos palabras que son importantes este para entender ese mecanismo que se da en el medio, si son request y response. Bueno, request significa, es lo que significa en inglés solicitud, pedido. ¿Sí? Eh, en este contexto que estamos trabajando, una request es el mensaje que un sistema le envía a otro, ¿sí?, para pedirle que haga algo. Sí, no es una intención eh vaga, no, no, no. Es una instrucción que técnicamente está muy bien estructurada, ¿sí? O sea, una request le dice al servicio que qué eh operación específica queremos ejecutar, ¿sí? Y le envía la información necesaria para poder hacerlo. Sí. Eh, cuando trabajamos con APIs, esto es muy muy importante, ¿no? Hay que pedirlo de una forma en el que el sistema lo pueda procesar, ¿se entiende? Sí. Eh, lo vamos a ver, como les decía, un poquito más adelante cuando veamos Jason en esta misma clase, un poquito más adelante, este, no demasiado profundidad, pero sí para que entiendan cómo funciona el pedido. Sí. Entonces, ese pedido tiene una estructura, tiene un destino, ¿no? Este, tiene datos que viajan, tiene reglas, ¿no? Y muchas veces tiene información sobre quién hace la solicitud y cuáles son los permisos. palabra importante que vamos a ver un poquito más adelante. Entonces, la request básicamente es el momento en el que una necesidad, vamos a ponerlo en estos términos, una necesidad funcional se convierte en un en un pedido, pero ya de carácter técnico. Sí, como les decía antes, ¿no? Una app, por ejemplo, educativa, ¿no? Tiene un botón que dice resumir este texto. Cuando el usuario, cuando el usuario lo toca ese botón, la app no resume el texto dentro de la aplicación en sí misma, lo que hace es armar una request, ¿sí? Para pedirle a otro sistema que realice esa tarea. ¿Sí? Entonces, en esa request viaja el texto. Eh, y, por supuesto, puede viajar eh junto con una instrucción adicional que puede ser eh hacerlo el texto breve y claro. Sí. eh o bueno, cualquier dato que sea necesario para que el servicio entienda cómo procesar ese ese pedido, ¿no? Entonces, eh por eso les decía recién, ¿no? Una request no solamente enviar un dato, sino que es una eh acción que está dirigida, ¿no? Tiene una intención eh operativa, ¿no? Y esa intención puede ser eh generar un determinado contenido, clasificar algo, resumirlo, traducirlo, este transcribirlo, etcétera. No es este, no es un paquete, digamos, de contenido sin texto, ¿sí? Es un contenido enviado paraar algo. Sí. Eh, entonces, bueno, en una request esto es importante. También suele haber por grado información que define qué es lo que queremos hacer, pero por otro lado también este información que constituye el material con el que queremos hacerlo. Por ejemplo, ¿no? En inteligencia artificial una parte del pedido dice resumir, ¿no? Y otra parte tiene ese texto a resumir. Bueno, se dan cuenta, ahí están estos elementos, ¿no? este que que mencionaba recién, solo a modo de ejemplo. Bueno, por supuesto una request puede ser este muy simple, pero también puede ser muy compleja, ¿no? Puede tener eh pocos campos o muchos campos, ¿no? Entonces eh obviamente ahí va a haber una una diferencia de tamaño, ¿no? Eh y no tanto de la función, pero sí este de la manera en la que eso se va a procesar, ¿no? Eh y esto tiene que ver con lo que veíamos antes de los ends, ¿no? Porque entonces define dónde pedimos algo y la request define cómo pedimos ese algo. Se entiende bien. Vamos a ver entonces ahora el segundo punto que es que es una response. Sí. A ver, si la request es el pedido, la response es la respuesta. La respuesta que vuelve del otro lado. Entonces, cuando una aplicación envía una request, ¿sí? El servicio la recibe, la interpreta, ejecuta la operación y después devuelve eh una response. Pero bueno, la response no es solamente lo que vuelve, ¿no? Es también una salida que tiene una determinada estructura, ¿no? Y que informa de alguna manera qué pasó con la solicitud, ¿entiende? Eh, básicamente, digamos, puede traer el resultado que nosotros estamos esperando, pero también puede traer otra información adicional, ¿no? Es decir, si la operación fue exitosa, si hubo un error, si faltó algún dato, si el sistema no pudo procesar el pedido, etcétera, ¿no? Entonces, eh una response no es solamente el contenido, ¿no? Sino que también eh es el estado, ¿no? Pensemos de nuevo en el resumen que les decía antes, ¿no? Si todo sale bien, bueno, la response trae el texto resumido, si algo falló, la response va a traer una indicación de error, por ejemplo, ¿no? O de rechazos. Entonces, eso significa que una response no solo comunica, digamos, este, ciertos datos, sino que también, por supuesto, comunica la falla, los límites, ¿no? Las condiciones que no se cumplieron, ¿no? Entonces, eh quizás desde la experiencia del usuario esto puede puede eh hacernos pensar como, bueno, esto anda, no anda, no funciona, algo se trabó, se rompió. Pero bueno, por debajo eh casi siempre hay una response que que está diciendo mucho más, ¿no? O sea, quizás tu pedido no fue válido, quizás hubo algún problema con la autorización, ¿no? Eh, tal vez el servicio estaba saturado, por ejemplo, ¿no? Tal vez la operación no se pudo ejecutar, eh, y devolvió algo distinto de lo de lo esperado, ¿no? Todo esto está en esa response, en esa respuesta, ¿no? Entonces, eh volvemos un poco a esta idea central que hablábamos antes de las APIs, ¿no? Una API no es una caja, digamos, negra que devuelve cosas que no tienen ningún contexto, ¿no? Es un sistema en donde tanto el pedido como la respuesta tienen una cierta forma, ciertas reglas, cierto significado, ¿no? Eh, y en una response específicamente podemos distinguir al menos dos dimensiones, ¿no? Una que es la informativa, ¿no? Es decir, qué contenido volvió. Acuérdense que acá, fíjense en el en el flujo completo que está arriba, ¿no? Ya hicimos la request, ahora tenemos ya hicimos la la el pedido del cliente, ahora estamos en la parte de la response, ¿no? Lo que la API nos responde. Bueno, eh por por un lado tenemos el contenido que volvió, ¿no? Y por otro lado tenemos la parte operativa, ¿no? Que es qué ocurrió con esa ejecución, ¿no? A veces hay contenido, ¿no? Este, o sea, recibimos un contenido, pero con ciertas advertencias. A veces no hay contenido porque la operación falló, a veces el resultado es parcial. Entonces, bueno, trabajar con APIs va a este a implicar también aprender a leer esas respuestas, ¿no? No solamente a mandar pedidos, ¿no? Acá me estoy imaginando a ustedes que quizás se ponen a trabajar con API desde el lado de la programación, por ejemplo, ¿no? Para que sepan de alguna manera cómo este interactuar con ellos, ¿no? Eh, bien. Bueno, acá les dejé en este en este slide algunos códigos de estados que son bastante comunes, ¿no? A la hora de de entender una respons dejé, digamos un ejemplo práctico acá este con eh algunos headers, ¿no? Y este y un poquito ahí de de código, este y una pequeña explic algunas ideas claves como pueden ver acá a la derecha y algunos y el flujo completo, ¿no? No, para que se lleven la idea de de qué es lo que lo que sucede en ese intercambio. Bien, ¿qué datos viajan en cada en cada una, no? Bueno, como les decía antes, ¿no? En todo en toda comunicación, como pasa en la comunicación humanas, este, y también en este caso con las APIs, ¿no? Hay un ida y vuelta de información, ¿no? La request lleva los datos que nosotros enviamos y la response trae los datos que la API este nos devuelve, ¿no? Entonces, en una request suelen viajar por lo menos tres cosas, ¿no? Primero, eh información sobre a dónde va el pedido, ¿no? Segundo, ¿qué operación queremos hacer? No, y después los datos que son necesarios para ejecutar esa operación. Por ejemplo, como les decía, ¿no? Una instrucción y un texto, eh una consigna visual, un audio, etcétera, ¿no? Pero además también puede viajar información de contexto, de contexto, por ejemplo, autenticación, eh, configuración, metadatos, ¿no? Entonces, una request no solamente el texto que mando, ¿no? Es toda es toda esa estructura completa, ¿no? Y del lado de la response pasa algo parecido porque vuelve el contenido principal, pero también vuelve información que ayuda a interpretarlo. E como les decía antes, si fue exitoso, si hubo advertencia, si la respuesta no está completa, eh si hubo algún problema, ¿no? Entonces, en una API el significado no está solamente eh en los datos, sino en cómo están estructurados. Sí, la estructura de los datos es muy importante, no alcanza con enviar un cierto contenido, sino que enviarlo de eh de forma tal que el sistema entienda qué representa cada parte. Sí. Eh, lo mismo al recibirlo, ¿no? Hay que saber qué campo es el resultado, qué qué campo describe el estado del proceso. Sí, más adelante, como les decía, vamos a ver esto en Jason, pero la lógica general básicamente es esta, ¿no? Request y response, eh, no son una masa caótica de de datos de información, no son estructuras muy bien organizadas y la consecuencia directa de esto es la calidad, ¿no?, este, de la integración. Sí. Este, entonces si un pedido está mal construido, sí, el servicio obviamente va a responder mal. Eh, y si la respuesta se interpreta mal, también la aplicación puede usar mal este un resultado que estaba eh bien, ¿no? Eh, entonces, bueno, básicamente en una request viajan eh la intención y los datos por un lado y en una response viajan el resultado y la información sobre lo que ocurrió. Sí. Bien, acá les puse eh un ejemplo eh completo o bueno, relativamente completo porque no se puede ejemplificar totalmente, ¿no? Pero de cómo funciona el intercambio, ¿no? Eh, como les decía antes, ¿no? Eh, imagínense en una plataforma educativa, ¿no? Una este un botón que dice explicar de manera más simple, por ejemplo. Entonces, el estudiante pega un texto, hace clic, la plataforma arma una request, esa request va eh en esa request, perdón, va la tarea, ¿no? Y va el texto, van las dos cosas juntas. La request se envía al end point, ¿correcto? Sí. A ese dentro del edificio que estamos, a la habitación correcta o a la oficina correcta. El servidor la recibe, ¿sí? El modelo procesa la entrada, devuelve una response. Sí. La response trae una explicación más clara, la plataforma la recibe y recién ahí la muestra en la pantalla. Entonces, desde la experiencia del estudiante fue como algo muy simple, ¿no? Pero desde lo técnico hubo todo un intercambio completo, ¿se entiende? Sí, hubo una API, hubo un endpoint, hubo una request, hubo una response y hubo una integración. ¿Sí? Bien. Esto simplemente para poner a modo de ejemplo todos los elementos que que venimos eh trabajando. Sí. E pensemos, por ejemplo, ahora otro otro caso, por ejemplo, ¿no? Una app de búsqueda semántica, por ejemplo, ¿no? Eh, no pide un texto, digamos, que necesariamente esté ya eh redactado, ¿no? Eh, sino que lo que pide son resultados que sean relativamente similares, ¿no? Bueno, hasta acá vimos que una aplicación envía una request a una API, ¿sí?, y que recibe una response, ¿sí? Pero nos falta entender algo muy importante que es en qué forma viaja esa información, ¿sí? que un poco lo adelantamos eh antes, ¿no? Porque por supuesto no alcanza solamente con saber que hay un un pedido y una respuesta, que es lo que venimos explicando, que es un poco el flujo, ¿no?, que hay eh en una en una API, ¿no?, sino que también necesitamos saber eh cómo es que se escribe ese intercambio, ¿sí? Y ahí aparece este concepto, ¿no? Esta idea tan importante, ¿no? Que es eh que se vincula obviamente con el trabajo de con las APIs, que es eh Jason. Sí, Jason. Eh Jason es una sigla también, ¿sí? Y significa JavaScript object notation. Sí. Eh, nuevamente con igual que con la que con la API, ¿no? Puede sonar este un poco técnico, ¿sí? Eh, pero bueno, tratemos de quedarnos con con la idea central, si se quiere, ¿no? Que básicamente Jason es un formato para organizar datos. Sí, es una manera ya estandarizada, ¿sí? si se quiere, de eh escribir información para que distintos sistemas puedan leerla y y procesarla, ¿no? Sin este ambigüedades, ¿sí? Básicamente es este una forma ordenada de representar datos. Sí, si quieren pueden pensarlo así. Entonces, cuando una aplicación, ¿sí? Una app se comunica con una API, sí, muchas veces lo hace enviando y recibiendo información en formato Jason. Sí. Eh, quiero hacer una aclaración para que se entienda. Jason no es la API, tampoco es el protocolo, tampoco es el modelo. Sí, es el formato en el que suele viajar gran parte de ese contenido. Vieron que venimos hablando recién de ese flujo de información. Bueno, eh esto es muy importante porque los sistemas cuando se comunican, sí, no pueden este enviar información eh de manera desordenada por todo lo que venimos hablando recién. tienen que estructurar tanto el pedido como la respuesta y Jason sirve exactamente para eso. Sí, exactamente para eso. Entonces, ¿cómo organiza la información Jason? Bueno, la idea es bastante simple, ¿sí? Y es la siguiente. Jason trabaja con pares, ¿sí? Pares de clave y valor. Pares de clave y valor. La clave va a ser el nombre de un campo. ¿Sí? Y el valor va a ser la información que está asociada a ese campo. Por ejemplo, modelo, ¿sí? Chat GPT, por ejemplo, o temperatura 0.7, por ejemplo, ¿no? Entonces, la clave lo que nos va a decir es eh qué es dato, ¿no? Y el valor va a decir cuánto o cuál es ese dato. Sí. Y esto es fundamental porque Jason no organiza la información como si fuese un texto continuo, ¿no? Sino que lo organiza como si fuesen campos con un determinado significado ya explícito, ¿no? Entonces eso hace que una API no tenga que adivinar, digamos, qué representa cada cosa, ¿no? Porque la estructura ya lo dice, ¿no? Entonces eh por eso es que es tan importante este concepto de eh objeto, ¿no? En Jason, eh, un objeto es todo un conjunto de pares, ¿no? Un conjunto de pares clave valor, ¿no? Que están agrupados entre entre llaves, como ven acá. Por eso les puse al principio donde en el principio de la infografía que dice que es Jason, eh, se los puse ahí entre entre llaves, ¿no? Porque un poco esa es la forma en la que se en la que se utiliza, ¿no? Entonces, eh, un objeto si quieren para hacer una analogía, ¿no? Es como una pequeña unidad de información organizada, ¿no? Entonces, si una request necesita enviar el modelo, ¿no? Este, el texto y algunos parámetros, todo eso puede viajar dentro de un objeto Jason, ¿no? Entonces, eh importante destacarnos que en Jason la forma es muy importante, ¿no? Las llaves, los corchetes, las comillas, los dos puntos, ¿sí? Las comas, etcétera, no están, digamos, este por eh decoración, ¿no? Sino que básicamente definen esa estructura, o sea, le indican al sistema eh qué es cada cosa, ¿no? Este, y cómo se relacionan eh entre sí. Sí, esto es muy importante. Yo acá les puse en estos eh seis este en estas seis viñetas, ¿no? Bueno, para qué sirven eh algunas ideas clave ahí separadas, ¿no? Un ejemplo muy muy rápido este para que entiendan cómo funciona, ¿no? Este y básicamente dónde dónde se usa. Les puse abajo algunos ejemplos reales de APIs en APIs, perdón, de inteligencia artificial. Este, pero bueno, Jason la verdad eh un sistema ya muy este universalizado, es muy conocido. Sí, pero bueno, eh, lo que quería presentarles por lo menos acá es qué significa y digamos para qué para qué sirve, ¿no? En principio, eh, bien. Entonces, para pasar en limpio, para que se queden con este concepto, la base de todo es la relación entre clave y valor. ¿Sí? Entonces, cuando un app recibe un Jason, eh, no va a estar leyendo solamente palabras, si se quiere, no sueltas, sino que va a estar leyendo toda una estructura en donde cada parte tiene un nombre y un contenido asociado. Entonces, si aparece una clave como prompt, por ejemplo, ¿no? El sistema va a saber que ahí viene una determinada instrucción, ¿no? Si aparece este modelo, por ejemplo, vas a ver qué modelo usar. si aparecen parámetros como temperatura, eh max tokens, etcétera, que eso lo vamos a ver en la clase 11, creo que es cuando veamos un poquito el tema de los Transformers, este y demás, este eso también, eh, va a a transmitir, ¿no?, una clave, este, digamos que va a estructurar todo el mensaje. ¿Sí? Eh, entonces, bueno, cuando agrupamos varias claves y varios valores entre llaves, básicamente es que ahí tenemos un objeto eh Jason, ¿sí? Entonces, un objeto es eh una colección, si se quiere, organizada de este campos, ¿sí? Eh, y eso se parece bastante, ¿no? Digamos, a cómo pensamos la información en en los sistemas este reales, quiero decir, ¿no? Usuarios, mensajes, solicitudes, configuraciones, todo suele representarse como objetos con propiedades, ¿no? Este, entonces, bueno, pensemos una request, ¿no? A una API de inteligencia artificial, por ejemplo. Puede ser un objeto que incluya el nombre del modelo, el texto de entrada, ¿no? Y algunos ajustes, por ejemplo. Entonces, la API recibe ese objeto, lee cada clave y en función de eso procesa cada valor, ¿no? Este, entonces, bueno, Jason lo que nos permite es convertir un poco lo que decíamos antes, ¿no? Esta necesidad eh funcional, ¿no? En una estructura que sea básicamente clara para para el sistema, ¿no? Pero bueno, todos los valores no son iguales. O sea, en Jason puede haber texto, puede haber números, puede haber valores que son verdaderos o falsos, listas, ¿no? puede haber otros objetos. Por eso, eh, básicamente, eh, Jason implica también saber reconocer diferentes tipos de datos, ¿no? No es lo mismo una frase con número, eh, un valor suelto que una lista, ¿no? Eh, cuando una request está bien armada, bueno, no solamente tiene la información correcta, sino que está bien organizada, ¿no? Y cuando una response vuelve en Jason, no solamente nos va a traer el resultado, sino que va, digamos, sino toda una estructura que permite identificar qué parte es el contenido principal y qué parte es el contexto. ¿Sí? Entonces, eh digamos esto esta idea que estamos trabajando, ¿no? Y este esto que estamos analizando de Jason nos deja, digamos, ver algo que es importante y es que digamos eh algo clave, ¿no?, es la comunicación entre los sistemas, ¿no? Eh, no solamente importan los datos cuando los sistemas se comunican entre sí, sino cómo están organizados esos datos. Sí, recuerden todo lo que veníamos viendo sobre esta idea del puente, ¿no? Del edificio. Este, bueno, ideas este digamos este simples, pero que nos ayudan a pensar un poco más esta cuestión que a veces puede eh resultar un poco compleja, ¿no?, al principio de entender, sobre todo para todos aquellos que quizás no están tan familiarizados con estas cuestiones de los objetos, las claves y los valores, ¿no? Eh, Jason, etcétera, ¿no? Eh, acá les dejé algunos conceptos, este, resumidos para que después los puedan ver, ¿no?, de qué es un objeto, ¿no? Este, un poco la la estructura básica, ¿no? Eh, la llave de apertura, ¿no?, que les puse ahí con la los pares clave valor, ¿no?, una llave de cierre. Bueno, examínenlo después. Cualquier duda, obviamente me consultan, ¿no? Pero les puse algunos valores muy comunes también para que ustedes puedan entender eh cómo es que se configura esto en la en la práctica, ¿no? E y un tema importante también es este, ¿no?, el de listas, el de las listas y de las estructuras, ¿no?, que están este anidad en Jason, ¿no? Porque básicamente en la práctica casi nunca alcanza con una estructura plana, ¿no? Es decir, por eso Jason incorpora estos dos recursos, ¿no? El de listas y estructuras sanidadas. Vamos a empezar por las listas para para tratar de clarificar un poco esta cuestión, ¿no? En Jason, una lista, ¿sí? Es una secuencia de elementos, ¿sí? que se escribe entre corchetes. Sí, se escribe entre corchetes. Pueden pueden contener textos, pueden tener números, eh objetos, este puede tener otras listas. Sí, pero listas son muy comunes en las APIs porque muchas respuestas que vienen eh nos devuelven conjuntos, es decir, nos devuelven varios resultados, varias este opciones, mensajes, ¿no? Por ejemplo, eh una API de búsqueda nos puede devolver una lista de documentos, por ejemplo, ¿no? Y cada documento puede ser un objeto con título, con un fragmento, con una puntuación. Entonces ahí aparece algo bastante típico, ¿no? Que es esto que les decía recién, una lista de objetos, ¿no? El el anidamiento, ¿no? En este caso es distinto. Anidar significa poner una estructura dentro de otra, ¿no? Un objeto que puede contener otros objetos, ¿no? Una lista, por ejemplo, puede contener objetos y un objeto a su vez puede contener listas. Eh, entonces, bueno, esto lo que hace es que eh nos digamos de alguna manera podemos este representar información eh digamos que sea mucho más rica, ¿no? Más realista. Por eso es lo que le decía de las capas al principio, ¿no? Este, entonces en una API de inteligencia artificial, una request, ¿no?, puede tener una configuración general y dentro de esa configuración general una serie de parámetros este más específicos, ¿no? Y una response puede traer este el resultado principal, pero este además no nos puede traer otro bloque con metadatos, ¿no? este con advertencias sobre el uso del modelo, etcétera, ¿no? Entonces, le les traigo estos elementos porque eh digamos nos va a ayudar a entender, ¿no?, que que existe una jerarquía de datos, una organización por niveles, ¿no?, donde unas cosas contienen a otras, ¿no? Eh, y Jason es muy bueno para poder expresar esas jerarquías y por eso se usa tanto en las APIs. Sí, obviamente cuanto más anidada es una estructura, más atención eh va a requerir leer esa estructura, ¿no? Porque obviamente no solo importa qué campos existen, sino obviamente dónde están esos campos. dos valores que son parecidos pueden significar cosas distintas según el el nivel, por ejemplo, en el que aparezcan, ¿no? Por eso eh en el caso de Jason no es solamente este reconocer ciertos símbolos, sino que también eh tiene que ver con reconocer ciertas eh relaciones, ¿no? Es decir, entender qué pertenece a qué en qué nivel está cada una de las cosas, ¿sí? Este, mucha en la práctica muchas veces muchas integraciones fallan, ¿no? No porque la la API esté respondiendo mal, sino porque la aplicación en todo caso no sabe en dónde buscar el dato correcto dentro de Jason, ¿no? Este, así que básicamente eh eh digamos entender las listas y las estructuras anidadas es algo muy importante, es una parte, digamos, esencial del trabajo este real con las APIs, ¿no? Eh, acá les puse algunos ejemplos eh reales de apis en inteligencia eh artificial. Fíjense, acá les puse, bueno, básicamente por qué es importante, ¿no? Y les puse un par de ejemplos para que puedan ver y algunas APIs reales, ¿no? En Open AI, en Antropic, en Shemin, ahí sí algunas ideas claves acá, este, como para que después puedan puedan revisar o o que puedan tener este para consultar si lo necesitan. Sí. Bueno, hasta ahora entonces vimos que una aplicación envía una request a una API, que esa request llega a un endp que eh la información suele viajar en Jason. Sí, en cada caso fuimos viendo, bueno, eh digamos este qué significa una API, cómo está compuesta, que es una request, ¿sí? Que es un endp eh y recién explicamos un poco de qué se trata esto de el formato Jason. Sí, la idea es que ustedes eh por supuesto después de la clase puedan profundizar en los temas que le interesen, pero e en esta clase la idea es contarles un poco qué es una API y cómo funciona, ¿sí? Desarmando un poco los elementos que constituyen todo el funcionamiento de la API, este con cierta profundidad, pero por supuesto son temas muy complejos, cada uno de ellos podría ser eh una clase. Sí. Eh, la carrera de programación se estudian cada uno de estos elementos por separado porque eh son bueno, componentes estructurales, ¿sí? Eh, y que es muy necesario conocer en detalle. Yo lo que les estoy contando un poco es el funcionamiento general y cómo interactú estos elementos. ¿Sí? Entonces, repito lo que les decía recién. Bueno, eh vimos que una aplicación, ¿sí?, una app cualquiera le puede enviar una request a una API, ¿sí? y que esa request va a llegar a un endpo habíamos dicho que los end points eran como estos departamentos dentro del edificio que es la API, ¿no? Y que la información suele viajar, ¿sí?, en una ruta en formato Jason, ¿sí? Pero bueno, falta este entender, ¿no?, para completar un poco el mapa, por dónde viaja todo eso, ¿no? Bajo qué regla circula todo este intercambio, ¿no? Bajo qué reglas se da todo este intercambio. Bueno, y ahí aparece uno de los conceptos más importantes y que seguramente ustedes deben conocer porque lo usan todos los días, ¿no? Que es el concepto de http. HTTP es una sigla también que significa hipertext transfer protocol. Sí. Bueno, obviamente eh nació sí en el contexto de la de la web, pero bueno, hoy se usa muchísimo más allá de las páginas este HTML, ¿no? Básicamente en términos generales, HTTP es un protocolo de comunicación. Protocolo de comunicación. le pero le les explico qué se entiende por protocolo. Bueno, un protocolo es un conjunto de reglas de reglas compartidas, ¿sí? Este que permite que en este caso dos sistemas se entiendan al intercambiar mensajes. Sí, no es una aplicación, no es una aplicación, eh, no es un servidor, sí, no es tampoco el contenido del mensaje, sino que es ese marco que define cómo se organiza la comunicación. Sí, básicamente HTTDP lo que hace es darle eh forma, ¿no?, al viaje de la información, si se quiere, ¿no? Entonces, gracias a al HTTP, una aplicación podemos decir que puede indicar qué quiere hacer, ¿sí? Y a qué recurso apunta, qué datos envía, cómo espera recibir la información, ¿sí? y el sistema del otro lado eh sabe cómo interpretar ese pedido, ¿no? Entonces, cuando una aplicación usa una API, ¿no? No es que esté inventando una forma de comunicarse desde desde cero ni mucho menos, ¿no? Sino que se apoya en un protocolo que está eh ampliamente estandarizado. Sí. Por eso, eh, básicamente intentar explicar que es una API sin explicar que es http es como digamos este eh aprender a escribir una carta ya no se gusta tanto, pero bueno, este y no saber cómo funciona el sistema de correos, quiero decir, ¿no? Es un ejemplo un poco vintage, pero creo que que se entiende la analogía, ¿no? Es decir, podemos mirar el contenido, pero falta entender el transporte de ese contenido. Entonces, HTTP pertenece a lo que podríamos llamar esa capa de aplicación, ¿no? Este no significa la no estoy hablando de la app del usuario, ¿no? Sino el nivel en donde se definen las reglas, ¿no?, del intercambio entre los programas, ¿no? Este, este protocolo HTTP no mueve, digamos, datos por sí mismos, ¿no? Porque eso lo hacen las capas más profundas, si se quiere, de la de la red. Lo que sí hace HTTP es organizar cómo deben presentarse y entenderse los mensajes. ¿Sí? Eh, y hay otra hay una una característica, bueno, que es fundamental de de de este protocolo HTTP, que es lo que se llama stateless. Stateless, es decir, sin estado. Eso significa esa palabra, ¿no? E digamos en en su forma básica, ¿sí? Significa que cada request se procesa de manera independiente. Independiente. O sea, el servidor no asume automáticamente este digamos que una solicitud recuerda al anterior. Sí. Y y ¿por qué puede ser importante, digamos, esto, no? Caso. Bueno, porque muchas veces cada request tiene que llevar dentro de sí toda la información necesaria para ser procesada. Sí. No se puede, digamos, confiar en que el servidor ya sabe, ¿no?, quién es, qué quiere, qué pasó antes, ¿no? Este, entonces, HTTP es un protocolo que organiza como una aplicación y un servidor intercambian solicitudes y respuestas. Sí, básicamente podríamos decir que es la gramática de esa conversación técnica, si se quiere. ¿Sí? bien, vamos a ver dos métodos, ¿no? Método get y método post, que si si recuerdan hace unos minutos yo les decía queaba esos métodos en la en la diapositiva que estaba antes. Bueno, si quieren después cuando terminen la clase lo pueden lo pueden eh revisar, ¿no? Pero bueno, si todos los mensajes nos podemos preguntar esto, ¿no? Si todos los mensajes viajan por el mismo protocolo, ¿sí? ¿Cómo sabe el servidor qué tipo de acción queremos? ¿No? Bueno, ahí entran los métodos HTTP, ¿no? Los métodos HTTP indican la intención principal de esa request, ¿no? O sea, le dicen al servidor qué clase de operación estamos intentando hacer, ¿no? Y eh vamos a enfocarnos en dos en este caso, ¿no? Para no extendernos mucho. Get y post, ¿sí? porque son los dos más comunes al trabajar con APIs y porque también nos van a ayudar mucho a entender la lógica en general, ¿no? El método GET se usa cuando queremos obtener información, sirve para recuperar una representación, si se quiere, ¿no?, de un recurso. Básicamente, get es hacer una consulta, ¿sí? leer datos existentes o pedir cierta información, eh hacer una lista de modelos, consultar una configuración, eh pedir el estado de una operación cualquiera. Y el método post se utiliza cuando queremos enviar información para que el servidor la procese. Sí, postamente consulta algo que ya existe, sino que envía un contenido nuevo y suele producir un efecto del lado del servidor, ¿no? Este, por ejemplo, e en APIs de inteligencia artificial, esto es muy común, ¿no? O sea, mandar un prompt, por ejemplo, enviar un texto para resumir, eh, bueno, pedir la generación de una imagen, como decíamos antes, pedir una transcripción, ¿no? Todo esto suele hacerse con este método post. Entonces, la diferencia básicamente conceptual eh es bastante clara. Get suele usarse para recuperar información. Sí. Eh, y post suele usarse para enviar datos, ¿sí?, eh, y pedir que el sistema haga algo con ellos, no importa qué. Sí. Eh, pero quiero remarcarles esto, no es solamente una cuestión de de sintaxis, no es solamente el get o el post, sino que es, digamos, una diferencia de intención, ¿no? Elegir entre estos dos métodos, get y post, ¿no? Es es parte de decirle al sistema qué queremos hacer, ¿no? Les doy dos ejemplos rápidos para para ponerlo en contexto. Si una app quiere saber qué modelos hay disponibles, sí, usa get. Si quiere mandar un prompt y tener una respuesta generada, sí, usa post. Sí, en ambos casos hay una request, pero el tipo de acción es distinto. Sí, por eso este para este digamos que que se comprenda, ¿no? Eh, quédense con esta idea. Get se usa en general para leer o para consultar y post se usa en general para enviar datos y pedir procesamiento. Sí, fíjense que volví a traer yo acá eh arriba de todo donde dice cómo funciona. Sí. el el diagrama de flujo, ¿no?, entre el el feedback, el y vuelta, ¿no?, entre el cliente y el servidor, la request y response, ¿no? Todo viaja por http, todo viaja por http eh utilizando en este caso estos protocolos que que recién les mencionaba, ¿no?, Ahora bien, fíjense, fíjense, esta infografía tiene bastante información, seguramente la pueden leer después, este, con mayor detenimiento, tiene información que creo que les puede resultar útil, ¿no? Pero una request eh con el protocolo HTTP no se va a definir solamente por el método, ¿no?, que veníamos hablando recién, ¿no?, eh, o por la dirección, ¿no? muchas veces necesita información adicional para que ese intercambio funcione bien. Tengan en cuenta que acá estamos pensando en intercambio de información. Eh, bien. Entonces ahí aparecen, ¿no?, eh los headers o los encabezados. Bueno, un header es un campo, un campo que acompaña esa request, ¿no? O la response y eh le agrega un contexto. Sí, en general no suelen tener eh no no suele contener eh digamos parte del contenido principal, pero sí suelen tener información que es clave para interpretar ese mensaje, ¿no? Por ejemplo, eh qué tipo de contenido se está enviando, qué formatos espera, ¿no?, en la respuesta o qué credenciales, por ejemplo, se usan para eh autenticar la solicitud, ¿no?, de usuario contraseña, etcétera. Eh, esto es muy importante porque las API keys que vamos a ver ahora eh en el próximo bloquejan justamente en headers, ¿no? Podríamos decirlo así. Eh, el cuerpo del mensaje, ¿sí? Dice, "¿Qué queremos hacer?" Sí, los headers dicen cómo leer ese mensaje y en todo caso bajo qué condiciones. Entonces, del lado de la response eh aparece este elemento fundamental, ¿no?, que son los códigos de estado, ¿no? Eh, el código de estado es un número que indica que nos indica por lo menos qué ocurrió con la solicitud que hicimos nosotros. Sí, obviamente no reemplaza el contenido, eh, pero sí le da un contexto. Les puse acá algunos ejemplos comunes, ¿no? 200, el código 200 significa que salió todo bien. Estamos hablando, vuelvo a decirlo, para para que no se pierda el hilo, ¿no? De intercambio de información. De ese intercambio de información. El código este 200, por ejemplo, significa que eh el resultado fue positivo o 400, que hubo un problema con el pedido. 401, ¿no? Eh, señala que hubo un problema de autenticación. No. Eh, este error yo creo que ustedes lo deben conocer, el 404, ¿no? Muchas veces les debe haber aparecido este error, este el error 404 cuando indica que el recurso no existe, ¿no? Bueno, todo esto no para nosotros a veces que somos usuarios no le prestamos demasiada atención, pero nos permite entender muy rápidamente dónde estuvo el problema. Sí, si una aplicación recibe el error 401 o bueno, o el código 401, sí, el problema no suele ser, por ejemplo, el contenido, sino que el problema está con la identidad, ¿no? Si aparece el código 404, cosa que seguramente les debe haber aparecido eh a todos en más de alguna oportunidad, eh probablemente esto esté haciendo referencia a que la ruta es incorrecta. La ruta es incorrecta, ¿no? Un error 400 puede ser un error en la estructura del mensaje, etcétera. Entonces, cuando la integración falla, ¿sí? eh no nos alcanza con decir, bueno, la API no anda, ¿no? Ahí sí hay que mirar el código de estado y cuál es la respuesta este asociada porque muchas veces está ahí la explicación, ¿no? Eh, entonces eh digamos los códigos de estado nos van a terminar informando el resultado de la operación. Sí, por eso es que eh digamos es tan es tan importante, ¿no? Yo les dije ahí al final unas buenas digamos cuatro cuatro buenas prácticas, ¿no? Que provienen de las personas que se dedican, digamos, al campo de la programación y que siempre recomiendan hacer, ¿no? Así como les decía antes, hay una muy buena práctica para todos aquellos que se dediquen en algún momento a programar o o se metan más en el tema de la la inteligencia artificial, el diseño, etcétera, traten de dejar siempre todo documentado, documentado. Este, ustedes seguramente en el futuro se se van a agradecer a sí mismos por haberlo hecho, porque les va a simplificar muchísimo la tarea, eh les va a evitar tener que volver sobre sus pasos, ¿no? Y también si ustedes trabajan en equipo, dejar documentado todo es muy importante porque le allan el camino, le permiten a quienes trabajan con ustedes entender qué es lo que ustedes están haciendo y no partir desde cero. Sí, esto es muy importante porque va a agilizar muchísimo el trabajo cuando ustedes trabajen con otras eh personas. ¿Sí? E les dejo en esta otra infografía un eh si se quiere un ejemplo relativamente completo, está bastante completo, de una llamada a una API, ¿sí? Paso a paso. Sí, paso a paso. Si ustedes tuvieran que eh hacerla en código, ¿sí? A ver, vamos a ver. Hm. Una aplicación, como decíamos antes, ¿sí? Esta aplicación imaginaria que estamos usando, de ejemplo, tiene un botón para resumir este un texto. Sí, tiene un botón para resumir un texto. Cuando el usuario lo aprieta, ¿sí? La app en ese momento arma una request http y usa el método post. Sí, porque está enviando un contenido para procesar. ¿Se entiende? La request se dirige a la URL del endp correcto. Sí, específicamente alp correcto. Incluye headers que indican el campo del contenido y si hace falta todas las credenciales de autenticación, usuario, contraseña, etcétera. Sí, en el cuerpo viaja el texto y todas las instrucciones, ¿sí?, de de ese resumen. El servidor recibe la request, interpreta el método, lee los headers, procesa el contenido y ejecuta la operación. ¿Okay? Después envía de vuelta una response. Si todo sale bien, va a responder con un código 200, ¿sí? y un cuerpo en Jason con el resumen. Y si hubo algún problema, bueno, nos va a devolver algún código 400, 401, 404, según sea el caso. ¿Sí? En este ejemplo que yo les puse, aparecen todas las piezas juntas, un poco de lo que venimos hablando, ¿no? Porque HTTP define un poco las reglas, ¿no? Eh, el método eh expresa la acción que se va a llevar adelante. Los headers, bueno, dan el contexto, ¿no? En el cuerpo se lleva el contenido, eh, y la response va a devolver el resultado del estado, ¿no? Eh, entonces reafirmo esto que un poco les venía diciendo antes, ¿no? trabajar con APIs no es solamente bueno, enviar datos, ¿no? No es solamente ese flujo de información, sino es construir una solicitud dentro de un protocolo. Dentro de un protocolo, ¿no? Y por supuesto saber leer eh las respuestas que también siguen ese protocolo, ¿no? Por eso hice hincapié este eh o quise introducir, digamos, este eh en este bloque la la el concepto de HTTP porque no es un detalle menor en la infraestructura, sino que al contrario es esa base sobre la que se apoya todo, absolutamente todo el intercambio técnico. ¿Sí? Eh, básicamente este protocolo convierte la comunicación entre una aplicación y una API. Sí, una aplicación y una API eh en un intercambio que tiene reglas, ¿sí? Y donde cada solicitud tiene un método, tiene un contexto, un contenido, una respuesta que se espera, etcétera. ¿Sí? Eh, muy bien. Y vamos a pasar ahora al punto siguiente, ¿no? Que es eh ¿quién está autorizado a usar este servicio? ¿Quién está autorizado a utilizar este servicio? Por supuesto, lo que vamos a ver tiene relación con la cuestión de la autenticación. Sí, vimos que es un API, que son los end points, cómo se arma una request, cómo eh vuelve, cómo retorna una response, ¿sí? En qué formato viaja la información, vimos también, ¿y cuál es el protocolo o bajo qué protocolo circula? Sí, vamos a agregar una pieza más que es la cuestión de la autenticación. ¿Sí? ¿Por qué? Bueno, porque una API, ¿sí? Este edificio del que venimos hablando desde el principio, ¿sí? Imagínense la API como ese edificio, ¿no? Ese edificio no suele estar abierta este la API, ¿no? El edificio abierto para cualquiera que le pida cualquier cosa sin control. Vuelvo, vuelvo al ejemplo del edificio. No todos tienen la llave del edificio. Sí, porque digamos quienes quienes están en ese edificio quieren mantener seguro su casa, si es su casa, su oficina, etcétera. Sí, y esto está muy bien que sea así, ¿no? Entonces, para entender este, digamos, esta cuestión de la autenticación, bueno, expliquemos un poco qué es autenticarse, qué es tener esta llave. Bueno, cuando hablamos de autenticación, hablamos específicamente de un proceso mediante el cual un sistema sí se identifica ante otro. Entonces, básicamente lo que demuestra es quién tiene permiso para hacer esa solicitud, ¿sí? O sea, autenticarse de alguna manera es presentarse ante un servicio, ¿sí? De una forma que este servicio pueda reconocer este como válida. Sí. Esto es muy importante, este porque una API sí no es solamente, digamos, una una puerta técnica, si se quiere, ¿no? No es una apertura técnica, sino que sí es una apertura técnica, pero es una puerta o una apertura controlada, ¿no? O sea, si un servicio ofrece acceso a modelos de inteligencia artificial, sí, este edificio, acuérdense, vuelvo sobre esta idea porque me parece que es útil para graficarlo lo que estamos pensando, ¿no? Si un servicio, si un edificio, ¿no? Dice, "Bueno, yo ofrezco acceso a modelos de inteligencia artificial, eso es lo que tiene el edificio, ¿no? En cada una de sus oficinas, ¿no? Tiene modelos de inteligencia artificial. Ese es el servicio que ofrece. Bueno, si un servicio ofrece acceso a modelos de inteligencia artificial, a procesamiento de datos o a recursos pagos, etcétera, tiene que decidir quién puede usarlo, bajo qué condiciones, cuáles son los límites, etcétera. Entonces, la autenticación es lo que hace posible ese control, ¿no? Entonces, acá dos conceptos que suelen confundirse muchas veces, ¿no? Que son la autenticación y la autorización, ¿no? Es lo mismo. Sí. E la autorización, si se quiere, va a responder a una pregunta este distinta, ¿no? La autenticación responde a la pregunta, ¿quién sos? A eso responde la autenticación, ¿no? ¿Quién sos? O más exactamente, digamos, qué credencial válida estás presentando para entrar. Y la autorización responde una pregunta distinta, ¿no? Que es, ¿qué estás habilitado a hacer una vez que entraste? ¿Sí se entiende la diferencia? Eh, una cosa es, digamos, no haber entrado, no correctamente y otra cosa es haber entrado, pero no tener permiso para esa acción. Sí, no tenés, podés entrar al edificio, pero no puedes ir al cuarto piso, se entiende y otro es directamente no puedes entrar al edificio. Esta distinción en en esto, digamos, en lo que se refiere a las APIs es muy importante, ¿no? Porque una aplicación puede tener la request perfecta, el endpo, eh el Jason impecable, ¿no? Y aún así recibir un rechazo. O sea, la app como hablábamos antes, ¿no? escolar que tiene, ¿no?, un botón que dice este resumir este texto, ¿no? Quizás toda la infraestructura está perfecta, ¿no? Pero aún así, al hacer clic ahí eh tenemos nos rechazan la operación. ¿Por qué? Bueno, porque no alcanza con hacer el pedido bien, ¿no? También hay que demostrar que se tiene derecho a hacer ese pedido, ¿no? Eh, entonces cuando una aplicación se comunica con una API, ¿no? Eh, no lo hace de forma anónima, lo hace presentando sus credenciales, ¿no? Las credenciales pueden ser tokens, pueden ser certificados, ¿no? O en muchos casos han usado ya una API, ¿no? La autenticación este es muy importante en este intercambio, ¿no? Y forma parte de alguna manera de esta conversación de la que venimos hablando, este flujo de información, ¿no? Entonces el servidor no va a mirar solamente qué pedimos, sino también desde qué identidad técnica lo estamos pidiendo. Por eso, cuando una integración este falla, no, no siempre el problema está en el en las credenciales, ¿no? Hay una credencial que está mal escrita, que venció un certificado, que no tiene permisos. ¿Si? Eh, entonces, bueno, eh elemento importante para tener en cuenta, sí, la autenticación. Acá les puse algunos métodos comunes de autenticación en APIs, ¿no? La API, ustedes van al chat GPT, por ejemplo, y quieren programar y quieren utilizar, ¿no?, chat GPT como ll, como modelo de lenguaje, eh pueden entrar en la configuración del chat GPT. Cada uno de ustedes tiene una API key que incluso les recomiendan que la guardenan, ¿sí? Para que este obviamente otras personas no puedan hacer uso de esos eh recursos. Sí, pero bueno, otras formas de autenticación en APIs también son tokens, este, usuario y contraseña son clásicos, sí, pero bueno, e simplemente digamos esto para entender que hay este, digamos, el acceso puede estar restringido. Sí. Y está bien que sí sea porque es una forma de regular eh este flujo de de información. Sí. Em una piqui, sí, les digo, quizás muchos de ustedes ya la han usado, es muy común. Cada uno de ustedes si usa chat CPT, por ejemplo, por ponerles un ejemplo nada más que venimos hablando, ¿no? Este, en estas clases, eh, van al perfil configuración y van a ver que ahí está su API key, ¿sí? Que es única para ustedes. Bueno, una API Key, digamos que es una credencial, ¿sí? este secreta podríamos decir, ¿no? Este que identifica una solicitud como perteneciente a una cuenta. En este caso ustedes si ustedes usan esa AP, ¿no? O puede ser un proyecto o a un usuario, etcétera. Sí, pero no es una contraseña, digamos, como eh digamos que que puede no estar, ¿no? Que está a modo ahí decorativo. Al contrario, es una forma de vincular una request con una identidad dentro del sistema. Sí. Entonces, básicamente gracias a esa clave es que el servicio puede saber quién está usando la API y aplicar permisos, medir un consumo, cobrar un consumo, imponer ciertos límites, ¿no? Y si hace falta y si es necesario revocar un acceso, eh, no, no permitir que ese esa persona, por ejemplo, ingrese al edificio, ¿no?, del que estamos hablando. Entonces, eh, la APIQ sirve, ¿sí?, por supuesto, para dejar pasar, ¿no? Para usar este término, eh esta analogía, ¿no? Del ingreso, pero también sirve para administrar el uso, o sea, para, como decíamos antes, ¿no?, para entrar al edificio y para recorrer sus instalaciones, ¿no? Eh, y esto es bastante importante en el campo de la inteligencia artificial, donde cada solicitud que hacemos puede consumir recursos, puede consumir este tiempo de cómputo, costos asociados, ¿no? Por eso que es importante y por eso una buena práctica es que cada persona o cada aplicación use siempre su propia eh API, su propia clave, ¿no? En lugar de usar una clave eh compartida, ¿no? Y eso es una buena práctica, ya que estamos hablando de buenas prácticas porque eh permite aplicar permisos mucho más precisos, ¿no? Pero auditar también mejor el uso, ¿no? y reducir muchas veces riesgos si una credencial se filtra, por ejemplo, ¿no? Eh, entonces, bueno, básicamente eh la API, sí, como para este cerrar esta idea, eh, básicamente digamos no hace nada por sí sola. Sí, no hace nada por sí sola. Lo que hace es este demostrar de alguna manera que la solicitud, el pedido que se está haciendo proviene de un lugar autorizado. Sí. Justamente por eso es que se trata de un dato eh sensible, ¿no? Porque si una API key se filtra este otra persona podría usarla, ¿no? Para hacer request este el nombre de esa cuenta, por ejemplo, ¿no? Eh, por eso es que no tiene que que compartirse, ¿no? Y y tampoco debería exponerse públicamente ese dato, ¿no? No no no son datos que tienen que se puedan subir o que deban subirse porque sí se puede, pero que no deban subirse a repositorios, por ejemplo, ¿no? Si ustedes entran en GitHub, eh eviten eviten este publicar eh estos datos, ¿sí? Porque como decíamos antes, son datos sensibles que deberían permanecer este bajo su dominio únicamente. Sí. Eh, bien, vamos a ver entonces cómo se envía una eh clave en una eh request, ¿no? Eh, una vez que entendemos que es una AP key, ¿sí? Eh, bueno, surge una pregunta que es obvia, que es dónde va esa clave cuando uno cuando una aplicación hace una una request, ¿no? Este, porque obviamente la autenticación no es este abstracta, no tiene que aparecer en ese intercambio técnico. Bueno, en muchas APIs la clave sí este viaja dentro de un header, por eso quise introducir antes la idea de de header, ¿no? Es decir, dentro de un encabezado de la request. Acuérdense que un header es un encabezado de la request. ¿Sí? Em, ya vimos, ¿no?, que los headers aportan un contexto eh, y la autenticación es uno de esos eh o de sus usos, si se quiere, más importantes, ¿no? En http, este, en el protocolo HTTP hay un header muy común para esto que es autorization. Autorización, ¿sí? En muchas APIs actuales se usa, ¿no? Eh, con el, bueno, se usa, no, no quiero ser demasiado técnico, pero se usa con el esquema Verer, ¿no? Significa básicamente esto. Esto significa que en ese header se envía algo como si digamos eh como lo que sigue, ¿no? Como lo que está acá, un barer seguido de la clave o del token. Sí. Eh, fíjense donde dice formato más común, autorization, arriba de toda la derecha. Ahí sí. lo lo explico. A ver, significa portador, ¿no? Eh, bien, no se preocupen igual por memorizar esta sintaxis ni mucho menos. Eh eh lo importante básicamente es que ustedes entiendan la lógica. Sí. ¿Qué quiero decir? Ustedes digamos este e en esta clase en este momento, no lo no lo muestro. En la clase que tuvimos el año pasado, lo mostramos en las clases sincrónicas en vivo de cómo conectar, por ejemplo, la API Key, ¿no? Este, con algún sistema para poder utilizar este chat Chiptando este mi propia este API key, ¿no? Y se bueno, la conexión se hace siguiendo una estructura muy eh muy particular, ¿no? Lo importante que que quiero decirles es que la clave no tiene que viajar mezclada con el contenido del pedido, sio que por eso les mencionaba antes lo de los headers, ¿no? Tiene que viajar en un específico pensado para la autenticación. Sí. Eh, por eso es que la cabecera, digamos, de autorización se ocupa de, en este caso, de decir quién hace ese pedido, ¿no? Entonces, bueno, gracias a a esa separación, ¿no? Este, eh, digamos un error de autenticación puede aparecer aunque este el Jason esté esté perfecto, ¿no? O sea, si la si falta la la cabecera, ¿no? Está si está mal escrita, si tiene una clave inválida, ¿no? Digamos, el servidor puede rechazar la RQUEST sin siquiera ni siquiera procesar el contenido, ¿no? Ahí lo más habitual que que suele aparecer es el error 401, ¿no? Este, que no significa que haya fallado todo, sino que lo que fallar no son las credenciales, ¿no? No hay credenciales válidas, ¿no? Eh, bueno, esto es muy importante para empezar a depurar después esas integraciones, ¿no? Porque todas las APIs no autentican exactamente igual, ¿no? Algunos, algunas usan otros headers o mecanismos más complejos, ¿sí? Pero el principio general es siempre el mismo. La credencial como el documento de identidad, la llave, ¿no? Tiene que viajar de la forma en la que el servidor espera y esa forma siempre va a estar especificada en la documentación. ¿Sí? Eh, entonces, bueno, básicamente como veníamos diciendo, una request en ese sentido va a tener dos dos capas, ¿no? Una dice qué es lo que queremos hacer. ¿no? Y la otra va a terminar demostrando que tenemos el derecho a hacerlo. ¿Se entiende? Fíjense arriba, ¿no?, donde dice dónde va la llave, la flechita, ¿no?, de tu cliente API, ¿no? O sea, eh digamos eh es eso quiero decir con lo que estoy diciendo ahora, ¿no? Eh, qué queremos hacer y si tenemos, ¿no?, el derecho a hacerlo. Bueno, todo eso eh es lo que va este incluido, ¿no?, de forma específica. Bien. Y bueno, acá al final quería dejarles algunas eh algunas buenas prácticas y algunos errores frecuentes. Quizás esto lo pueden tener, digamos, como ayuda memoria o pueden venir y consultar si en algún momento les resulta este útil, ¿no? E pero bueno, digamos, la idea es acá, digamos, aportarles algo quizás un poco más del lado, no sé si profesional, pero para aquellos que vayan a hacer uso de algunas alguna de estas herramientas de manera profesional, ¿no? Eh, una piquí filtrada, sí, no es un error menor. Sí. Eh, digamos puede generar consumos indebidos, este pérdida del control del del entorno que se está manejando, problemas de seguridad muy serios, es como perder, por ejemplo, una tarjeta de crédito, si se quiere, ¿no? O el documento, ¿no? Eh, por eso es que hay recomendaciones muy claras al respecto, tales como les decía antes, ¿no? No compartir las claves entre las personas, este, cada uno debería tener la suya propia y no compartirla, no exponer la clave. digamos, en el lado del cliente, quiero decir, como en un navegador, en una este app móvil, ¿sí? no subir la clave a repositorios, la API Keq estoy hablando, por ejemplo, no en este caso, eh, a repositorios como GitHub, si no están correctamente ocultas, ¿no? Eh, bueno, elementos, ¿no? Este, que que les van a permitir a ustedes eh eh asegurarse, ¿no?, de que, bueno, los riesgos van a ser este menores, ¿no? Básicamente, eh me gustaría que se queden con una idea, ¿no? Eh y después, como les digo, si tienen dudas o consultas, me dicen un poco, digamos, lo que tienen las clases asincrónicas, es que, bueno, falta quizás el feedback de la parte de ustedes para ir resolviendo consultas en el momento, ¿no? O poniendo ejemplos prácticos en el momento a medida que van surgiendo las dudas, ¿no? Pero me parece importante lo siguiente, aprender a trabajar con con APIs, si familiarizarse con las APIs, ¿no? No es solamente aprender a a mandar una request, ¿sí? Sino que implica también una un aprendizaje eh acerca de cómo comunicarse técnicamente, pero de manera responsable. ¿Sí? Es decir, siguiendo una cierta estructura con ciertas reglas. No, con cierto cuidado por la seguridad, ¿no? Eh, entonces, bueno, eh, nada, básicamente me gustaría que se queden con esta con esta idea y recapitulando un poco lo que decíamos al principio de la clase, ¿no? Eh, una API, sí, porque estamos estamos haciendo un curso de de herramientas de inteligencia artificial. Sí. Y una API es muy importante porque una API nos permite acceder a una capacidad externa. Traigo, digamos, este nuevamente el concepto que vimos al principio, ¿no? Una API nos permite acceder a una capacidad externa. Si yo tengo una aplicación, construyo una aplicación eh y no y por ejemplo quiero acceder a a un modelo de lenguaje, sí, a un LLM, quiero yo construyo una aplicación de, como decíamos, ¿no?, una aplicación escolar, ¿sí? Para uso escolar, donde los alumnos puedan subir sus textos. Y lo que yo quiero ofrecerle a los esos a esos alumnos es que suban sus textos, que los puedan resumir, eh que los puedan este, no sé, pasar a PDF. Sí, etcétera. Lo lo que a mí se me ocurra hacer por una aplicación o una página web, etcétera. Bueno, no necesariamente yo tengo que construir toda la infraestructura. No tengo que construir un modelo de lenguaje, una inteligencia artificial, un convertidor de PDFs, no. Yo lo que tengo que hacer, sí, es conectarme a las diferentes APIs. Vieron que muchas veces dicen este que los buenos equipos se forman no con personas que saben todo, sino con personas que saben a quiénes llamar. cuando tienen un problema. Sí. Bueno, esto es lo mismo. Básicamente un API, este, digamos, lo que nos permite es acceder a una capacidad externa, a un recurso que nosotros no tenemos y que necesitamos. Sí, la API es eso. Sí, los ends que vimos al principio ordenan esas capacidades. Los end points, acuérdense, eran como estos departamentos dentro del edificio, ¿no? Supóngase que yo quiero resolver x problema, se a qué edificio ir. Bien, dentro del edificio tengo que ver a qué lugar se encuentra el departamento específico que me puede dar la solución a ese problema. Bueno, esos son los ends que van a ordenar esas capacidades, ¿no? Las request y las response lo que van a hacer es estructurar ese intercambio. Sí, ese intercambio. Jason lo que va a hacer es organizar los datos, ¿sí? y HTTP lo que va a definir el protocolo. HTTP va a definir las reglas en las que se transporta esos datos. ¿Sí? Y por último, la autenticación nos va a asegurar que el acceso a ese edificio y a las oficinas que están dentro de ese edificio sea válido. ¿Sí? Eh, entonces, básicamente, eh, un poco todos estos elementos fueron los que este intentamos revisar, ¿no?, este, a lo largo de la de la clase. Espero que les hayan quedado claros. Como les digo, si tienen alguna duda o consulta, eh, me dicen, no hay ningún problema, me escriben. Eh, puede ser a través del del grupo de WhatsApp o si no por el por el campus, no hay ningún problema. Eh, no se olviden, por favor, de responder el formulario de de Google eh para poder eh pasarles la asistencia. Sí. Y eh cualquier cosa que necesiten, repito, nos pueden escribir y eh nos estamos eh viendo dentro de 15 días. Les mando un abrazo grande a todos. M.