 otra charla en el track de Abaisio Super, interesante. Tenemos a Paulo, que es licenciado en Bellas Artes y desarrollador web full stack. Lleva más tiempo en esto de lo que quería reconocer. Y ahora mismo trabaja como freelance. Es experto en WordPress encodeable y le gusta leer la playa, la tipografía y como no el cine. Hoy nos va a hablar de usar HTTP para consumir recursos externos. Nos explicará de qué se puede hacer con el API de WordPress y algo más. Adelante, Paulo. Gracias. Hola. Muchas gracias a la organización y por haber elegido mi ponencia. Espero que nos aburra mucho porque va a ser un poco espesita. Ya os aviso de entrar. Bueno, ese señor soy yo, ya me han presentado. Esto es lo que vamos a ver. ¿Para qué sirve? ¿O qué podemos hacer con la API HTTP de WordPress? La lista de funciones porque básicamente es una enumeración, lo que voy a hacer porque tiene una serie de funciones. Os las voy a detallar y luego vamos a ver un pequeño ejemplo muy sencillo de cómo usarlo. ¿Para qué sirve? Pues sirve para consumir otras APIs, APIs externas a nuestro propio WordPress. ¿Qué significa consumir? Pues que podemos enviar, recibir y manipular datos a través del protocolo HTTP, que como sabréis es la base de la comunicación entre aplicaciones en internet. Y para eso que se usan pues los verbos HTTP comunes que son los que funcionan, los que hacen funcionar el protocolo y gracias a los que las máquinas se entienden y a los que podemos... Mucho ruido, ¿no? Gracias a estos verbos podemos consumir y manipular la información. Esto es un listado de ejemplos de cosas que se pueden hacer, que no deja de ser lo de antes. Traer o enviar información y manipularla en el proceso. Entonces, pues bueno, podemos enviar noticias, listados, datos, los que sean. Podemos interactuar con un WordPress, un WordPress que esté en otra parte. Interactuar con aplicaciones móviles. Podemos, por ejemplo, si me ocurre usar un WordPress como back para una aplicación, que la aplicación sea al front, vendría a ser lo mismo que el WordPress que les enviar actualizaciones a otras webs, loguearse, por ejemplo, con los datos de otro servicio o de otro proveedor o incluso al hacer un registro en nuestra web, generar un login en otro servicio, en otra web. Y una cosa que no sabía, hasta que he preparado la charla, pero se pueden enviar y recibir archivos, porque al final son datos lo que mantas y un fichero binario se puede mandarte. Lo que pone abajo. ¿Qué se puede hacer? Pues lo que hacen todas las APIs. Os voy a dar ahora las funciones nativas de WordPress. Son muy básicas y genéricas y se corresponden con los verbos con los verbos que hemos visto antes. Get para recibir, pues para enviar, Get para leer cabeceras y tiene una genérica que es request que sirve para los verbos que no tiene como función explícita. Al usar el request dentro de los argumentos podemos decirle, por ejemplo, para hacer un delete o otro tipo un put, por ejemplo, que no está aquí y que son verbos comunes. Todas estas funciones están en este fichero, vpincludge, http.php, para sorpresa de nadie. Y todas estas funciones son un wrapper de una clase que también está en el mismo directorio. En realidad, lo que hace WordPress es, nos está sacando estas funciones para que sea más fácil o cómodo usar la clase www.http. Estas funciones tienen sus primas con el safe, vp safe, remoto request. Son las mismas funciones, solo que lo que hace es, pasa las URLs por esta función, que lo que hace es, no es que se anifique, pero hace una serie de chequeos para que, digamos, estas llamadas a servicios externos sean más seguras. Yo creo que fue sobre la versión 3 de WordPress 3.2, hubo hay un hype de que WordPress no era seguro y entonces hicieron como una auditoría muy fuerte sobre todo el code base WordPress y a raíz de aquellos sacaron estas funciones safe. Entre estas y las otras, prácticamente lo mismo, usar estas, porque se supone que son más seguras, pero hoy por hoy prácticamente son equivalentes, simplemente. Otro lote de funciones auxiliares, las anteriores, digamos, son para hacer las propias peticiones o los envíos y estas sirven para manipular la información que recibimos, en el caso de hacer peticiones que nos traigan información. La primera, el response code, pues son los códigos que nos da el protocolo, todos conoceréis el 404 o el 200, que es que todo va bien, 500 que es un error de servidor. Simplemente esa función, le pasamos la respuesta que nos ha dado al hacer la petición y nos devuelve el código, la siguiente nos devuelve un mensaje, o sea, la de arriba nos daría el 404 y la de abajo nos daría el not found, digamos, o sea, es el mensaje de texto. Heders nos devolvería, nos daría todas las cabeceras de esa petición, de esa recuesta. La siguiente header nos daría una sola, la que le pasemos al pedir el header, o sea, podemos pedir un header específico en vez de todos que es un Array. Y la última, digamos, que es la que estamos esperando, o la que nos va a devolver el body, digamos, el bloque de datos de la transacción que estemos haciendo en este momento. Hay tres más que sirven para manipular cookies. La misma línea, ya os digo esto al final, es un poco enumeraros para que sepáis si tiráis de la documentación de developer de Wordpress, la tenéis ahí muy detalladas. Y una cosa que os recomiendo, si os interesa esto, es ir al propio código, a la clase que está en WP Includes, que se llama HTTP. En la charla de Fernando me he enterado que hay un filtro para manipular los argumentos antes de enviarlo. Yo no me había fijado en eso y no lo he incluido, pero mira, está bien, siempre se aprende algo. Vale, esto sería un ejemplo de petición, un request. Lo vamos a guardar en la variable response, hacemos una petición a un URL y le pasamos unas series de argumentos. Y lo que hacemos aquí es chequear que lo que nos devuelven es válido para nosotros. Si es válido, o sea, si el response es una RAI y además no es un error de Wordpress, un WP error, un objeto WP error, pues podemos sacar los headers, traer el body y en este caso, si ese body que nos llega está en un formato JSON, como lo queréis llamar, pues podemos usar la función JSON de code para convertir ese string en JSON en un RAI. Lo siguiente que vamos a ver sería los argumentos, este RAI se corresponde, vuelvo para atrás, con estos argumentos que pasamos al hacer la petición. Un body que sería el cuerpo, esto por ejemplo sería un post, porque si estamos recibiendo información, no vamos a enviar un body, perdón. Y una serie de parámetros, hay muchos más, de hecho es que son innumerables, al final una petición HTTP, tanto los headers como los parámetros estos, no digo infinitos, pero bueno, hay un montón. Y esto es un ejemplo. Ahora os voy a enseñar lo que sería un ejemplo de body, por ejemplo, de enviar un formulario por post, sería esto, simplemente un RAI. Imaginar que esto es un formulario y le da ese al botón enviar, pues al hacer un request a una URL y pasarle los argumentos que hemos visto antes y este body, simplemente estaríamos enviando un formulario, que digamos otra parte de nuestra propia web va a recibir. Y otra de las variables importantes que vamos a pasar son los headers, porque muchas veces en estos headers nos puede hacer falta autentificarnos o tenemos que mandar la información en un formato, y uno repetido, me da cuenta esta mañana, pero ya no me daba tiempo el content type, está dos veces. Y esto un poco lo mismo, headers, te los puedes inventar, tú puedes pasar headers propio entre una aplicación y otra, si las dos son tuyas, te los puedes inventar. Hasta ahí toda la chapa teórica, ya habéis visto que son nada, no sé qué calcula, ocho, diez funciones, no llega, hay alguno más. Como siempre que doy una charla, aprovecho para aprender algo que no sea, así que se irá a ser buenos con las preguntas luego. Estuve buscando un patrón de programación orientado a objetos que me encajara con esto, que me serviera para ponerlo en práctica, y di con el patrón strategy. Es un patrón bastante sencillo y que nos permite la definición, da un poco de miedo, pero es una cosa bastante sencilla. Es definir en capsular un lote de algoritmos que luego nos permite, si nos hace falta, en ejecución cambiar de lote, digamos, porque según lo que necesitemos hacer en la propia ejecución, nos puede interesar, digamos, seguir una estrategia u otra. Entonces, ¿qué hace que las partes móviles de una clase que hace una petición, lo que hago es traerlas? Vamos a ver código ahora y os voy a explicar. La manera en que yo la he implementado es muy sencilla. Hay dos interfaces que nos van a permitir hacer objetos intercambiables de las clases de los requester, se los he llamado, las clases a través de las cuales voy a hacer las peticiones, y de los parses, porque yo puedo llamar a una API externa y la información me la da en un formato u otro y puedo llamar a otro servicio y me va a dar la información de un servicio, o sea, de una manera o de otra. Y yo necesito estructural esa información parsearla para que sirva mis intereses. Ya os digo que vamos a ver código ahora. Entonces, como ejemplo, lo que he hecho es construir un pequeño plugin que usa este patrón, y lo que hace es llama a dos APIs. He cogido dos APIs públicas. La de Chuck Norris devuelve una frase, una fecha y poco más, y la de la Guerra de las Galaxias, la petición que hago en concreto devuelve personajes. He cogido dos muy diferentes porque una simplemente me da un string y una fecha, si no me equivoco, y la otra me da un montón de datos estructurados. Lo que quiero que veáis es el patrón estrategia, como digamos a grupo la petición y su parser, pues lo interesante es que fueran muy diferentes unas de otras. Lo que hace el plugin es llamar a un endpoint, o sea, hacer un request, comprobar que lo que recibimos es lo que queremos y que está bien lo que hemos visto en el pequeño trozo de código antes, que es comprobar que es un arrailo que recibimos y que no es un error. Parsear esa respuesta que hemos estado comentando porque lo que queremos con esto es hacer una importación, hacer crear post en nuestro propio WordPress. Entonces tenemos que estructurar esa información que recibimos de manera que la podamos importar como post. De todos esos pasos, en el request es diferente la petición a una API que a otra API los argumentos que tengo que pedir son diferentes, en una y en otra. El parseo, como ya os he dicho, también es diferente, pero el import es el mismo, porque yo al final lo que voy a hacer es un WP post insert, creo que es la función, ahora la vemos. Entonces, digamos, las partes móviles son el request y el parseo. Esto sería la petición. El check request es una clase que yo me creo que recibe esos dos argumentos. Recibe la URL a la que voy a hacer la petición y el objeto parser, el que hemos creado a partir de la interfaz de parseo. Porque de esa manera vamos a ver que no en esta función, esta es la clase. Simplemente, recibo la URL, recibo el objeto parser y aquí defino los argumentos con los que voy a hacer la petición. Y luego en la siguiente función que ahora la vamos a ver es cuando hago la petición y con la información que recibo. Bueno, aquí está un poquito más complicado. Hago una pequeña capa de cache. Simplemente, para no hacer peticiones todo el rato, lo que hago es cuando hago una petición y es correcta la guardo como transient. Es un cache de parbulario, vamos a decir. Entonces, primero chequeo si ya tengo la información. Si no hago la petición, le doy un superremote get a donde a la URL que pasaba la clase y con los argumentos que he definido el constructor. Si la petición es correcta, me da un código 200, guardo el transient para que la siguiente vez que se ejecute esto ya no haga la petición, ya tengo esa información. Ya os digo, es una cache de juguete. Pruebo si lo que recibo es correcto y si no lanza un error. Y luego lo que hago es la información que he recibido, el body, se lo pasó a mi objeto parser, que ahora vamos a ver el objeto parser, lo único que voy a hacer es, ya os he dicho, estructurar un poco la información para después si esa información es válida y no está vacía, simplemente con un bucle lo importo en mi WordPress. Genero posts automáticamente sobre la información de ese request que he recibido de Jack Norris o de la Guerra de Galaxies. Entonces lo que nos queda por ver es el parser. El parser como habéis visto lo que vuelvo para atrás, lo que yo le pasaba al parser es el body, el cuerpo de la información que he recibido y lo único que hago, digamos, esto es lo que a mí me ha dado la petición, el request. Esto es cada uno de los items, si no me equivoco a la de Jack Norris, devuelve 70 y no sé cuántos de golpe. Lo que hago es tomar la información y dame la formato y lo que hace aquí es darle un formato de post. Cojo el valor, la fecha en la que se ha creado, cambio el status ha publicado y lo meto en una rai que es lo que voy a devolver. Y eso es todo. No sé a qué velocidad de ir o no mirá. ¿Tenéis alguna pregunta? Muchas gracias por la charla. ¿Hay alguna ventaja entre en tema de rendimiento o cualquier otro entre usar la ad binativa o usar CUR o lo que trae por defecto PHP? Yo creo que no, pero como siempre, si estamos trabajando con WordPress y WordPress no se lo da, pues lo tienes, lo tienes a mano. ¿Qué quieres usar CUR? Bueno, pues usar CUR, pero tienes unas funciones ahí como de super bajo nivel que te van a facilitar mucho la rendimiento. Igual el CUR directamente es un poco más porque no tiene que ejecutar las clases pero yo creo que a efectos da lo mismo la cosa. ¿Alguien más? Se deja planchaos. Bueno, yo no soy programadora, así que tengo aquí un par de preguntas preparadas. No os penséis que es por mí. Yo no sé qué estoy preguntando, lo voy a contestar. Vamos a preguntar. Hola, Pablo. Felicidades por la charla, que ha estado genial. Y mi pregunta es muy, muy breve. ¿Se podría interactuar? Tú has mostrado un par de APIs que nos devolvían unos datos de ejemplo, pero con una API pública comercial de otro tipo, es decir, más comercial, más seria. Sí, de hecho con cualquier API. En el ejemplo, bueno, era prácticamente pseudo código, si tú tienes una API comercial contra la que te tienes que validar como usuario, lo que vas a tener es que pasar en los headers un método de autentificación, ya sea un token o un basic out que no lo recomiendo, pasar el usuario y contraseña en texto plan. Con eso ya te validas y la petición y el resto del proceso es exactamente el mismo. ¿Y todo esto merece la pena? No, pregunta. Ya he dicho que no soy programadora. Atención a la pregunta, dice. ¿Merece la pena todo este lío de interfaces y de OPP para un plugin sencillo? Para este ejemplo, pues no, pero bueno, como lo que quería digamos era un poco de mostrar la manera o como se puede hacer. Incluso para esta cosa tan sencilla, en el momento que ya tienes dos peticiones y son diferentes, ya puede merecer. Porque si estás en un escenario en el que no sabes cuántas peticiones van, imagínate que es un cliente y dice, bueno, yo voy a necesitar esta información y es posible que igual luego está ahí esta otra, pero no lo sé, pues te estás curando en salud porque estás haciendo un sistemita muy sencillo, sencillo dentro de su lío, pero que es muy flexible. Con hacer pares de clases y cambiar la URL y los argumentos que pides y el parseador ya es como muy ágil el funcionamiento. Ángeltino, una pregunta. Han cantado la... Claro que se puede usar para... Yo no usaba y usaba CUR para estas cosas, pero creo que es más interesante esto. Por ejemplo, imagínate que va a guardar generar un PDF, un título y lo quiere firmar digitalmente, lo envía y recibe la respuesta, lo puede hacer con esta vía, por ejemplo. Es muy útil. Sirve para cosas interesantes, sin duda. Otra pregunta que probablemente os resulte interesante. ¿Por qué usar las funciones auxiliares en vez de atacar el array directamente? Pues un poco por lo mismo que ha preguntado José. ¿Tienes las funciones? Puedes usar... lo que dices, puedes atacar el array porque el recuesto al final es un objeto, no es un array, no es un objeto. Y está ahí, tú lo puedes usar como quieras, pero teniendo funciones específicas para ese labor es siempre mejor utilizarlas. Gracias por avisarla, muy interesante. Una pregunta. Imagínate que tengo un RP que tiene 12.000 productos y quiero conectarlo con un Google Comer. Intercambio básico de información. Lo que es simplemente catálogo, stock y a lo mejor alguna descripción de imagen que utilizarías directamente con conexión directa o meterías un tercero para hacer esa conexión y que no se perdiese por rendimiento a lo mejor o por otras complicaciones de intercambio de información. Prior y yo lo haría directamente porque salvo que necesites eso algún sistema de caché intermedio o algún tipo de filtraje de esa información. Si no, no veo la necesidad. Entiendo que puedes necesitar un proxy en medio para que incluso de protección de la información en casos concretos. Yo haría las peticiones directamente. Una advertencia. Me he dejado una diapo con recursos y he dejado el código que hemos visto. He hecho un pequeño plugin. Usarlo con precaución en un WordPress que no valga para absolutamente nada porque según activas el plugin hace petición a las dos APIs que os he enseñado. Se trae y de repente tienes 85 posts y cuando recargas la página tienes 85 posts más y para cuando has pestañado tienes una base de datos con 1.800 posts. ¿Y a ver si coge las manjacks? Eso es. Entonces tener mucho cuidado. Es una pura demostración teórica. No lo instaléis en ningún WordPress que valga para nada. Cada vez que recargas hace las peticiones y aunque le he puesto esa pequeña seguridad del cache con el transient el import lo hace y lo hace. Va a petar de post en un momento. Pero bueno, ahí tenéis. Mirar las referencias os recomiendo especialmente este artículo de Torque que mirad de qué año es de 17 y que sepáis que la clase vphttp que tiene un proxy por delante es un proxy a la vez de otra clase que mantiene Ryan McKeogh que no sé si eso suena pero es el alma mater de la rest API de WordPress. Entonces bueno, hay una información ahí muy interesante y ya no os voy a la chapa más. No sé si hay más preguntas. Bueno, yo quiero darle las gracias a Paulo pero antes de darte tu regalo, Paulo, tengo dos anuncios por parte de la organización. Deciros que nada, en apenas cinco minutos tenemos la foto en el track de...