Yo alucino de verdad con estas cosas.
A mí me parece algo histórico.
Luego hay un montón de gente que no lo ha entendido del todo bien,
pero bueno, estoy aquí para explicarlo.
Histórico. Nuevo método HTTP propuesto.
Se llama Query y es una alternativa a Get y Post.
Es como Get porque no modifica el estado del recurso.
Es como Post porque puede usar el body para la petición.
Y lo mejor es que puedes cachear las respuestas.
Y aquí tendríamos la propuesta de este nuevo método para HTTP.
No es una cosa que pase todos los días.
¿No estaba ya? No, no estaba ya.
De hecho, aquí tienes la propuesta que ha sido publicada el 14 de septiembre del 2024.
De hecho, es una propuesta que tampoco está 100% seguro que vaya a ocurrir.
Yo creo que sí que ocurrirá porque he estado viendo un poco el estado del memo y tal
y tiene bastante buena pinta de que se ha trabajado bastante y tal.
Yo creo que sí va a ocurrir.
Y creo que tiene todo el sentido del mundo porque hay mucha gente que no ha entendido exactamente esto.
Pero ahora yo creo que cuando lo expliquemos un poco, vamos a ver por qué.
El tema es que lo bueno que tiene esta propuesta es que muchas veces estábamos utilizando...
Esto es, normalmente utilizamos el Get cuando hacemos una petición para obtener datos.
Vamos a midudep, por ejemplo.
midu.d no.
midudep.
Midudep.
Cuando vas a midudep, por cierto, de midudep os voy a contar una cosa.
He estado subiendo nuevas clases del curso de últimas novedades de JavaScript que si eres suscriptor tienes acceso gratuito
y que sepáis que ya tenemos el primer capítulo entero y además el último capítulo, el de los métodos de SET.
SET es una estructura de...
Es verdad que lo he hecho yo, es verdad que lo he hecho yo, ¿vale?
Pero, hombre, que nos lo hemos trabajado, que fijaos que...
Mira, mira, mira, hay unos gráficos y todos que hemos puesto gráficos.
Son clases que van directas y al grano, ¿vale?
Que son rápidas para que aprendan lo que tenéis que aprender.
No esto de un curso de 20 horas para...
No, son clases que van directas y al grano para gente que quiere aprender rápido, pero bien.
Así que ahí lo tenéis, ¿vale?
Bueno, pero esto no es lo que os quería comentar.
Lo que os quería comentar es que cuando vosotros hacéis una petición, normalmente el método que se utiliza es el de GET, ¿no?
Porque estáis recuperando datos y ya está, no tiene mucha historia.
Pero cuando queréis escribir datos en el servidor y queréis crear un recurso, utilizaríais POST, ¿vale?
Vale, hasta aquí bien.
¿Qué es lo que pasa?
Que GET tiene algunas carencias, digamos, a la hora de utilizarse.
Y es que lo único que podéis hacer para pasar parámetros a la petición con GET sería la URL.
Solo podéis utilizar los query params, los parámetros de la URL.
Por ejemplo, cuando hacéis una llamada, una búsqueda, tenéis que hacer, vale, pues barra search y tenéis que pasar todos los parámetros de la URL
porque no se puede pasar por el cuerpo de la petición.
En cambio, en POST sí que lo podéis hacer.
En POST sí que podéis utilizar el content body y ahí le podéis pasar, pues, todos los parámetros.
Aquí tenéis el ejemplo, ¿no?
Aquí tenéis el POST, ¿veis?
Y aquí tenéis que le podéis pasar con el content body, le podéis pasar, pues, todo el cuerpo con un formato JSON, con un formato de diferentes cosas.
Vale, hasta aquí bien.
¿Cuál es el problema?
Que porque como pasa esto, como ocurre esto con GET, que se tiene que utilizar la URL, el problema es que hay veces, que esto lo hemos visto muchas veces,
que tienes que, imagínate un filtro de búsqueda, como por ejemplo Google.
En Google pasa muchas veces, ¿no?
Que si buscas algo, vas a ver que aquí en la URL empieza a meter una de información bestia, ¿vale?
Porque lo tiene que pasar por la URL y empieza a metirte aquí una de cosas que ocupan un montón y cada vez puede ser un poco más complicado y tal.
El problema es que GET tiene, o sea, la URL tiene un tope, tiene un límite, que puede ser según el navegador, el dispositivo, lo que sea, puede ser desde 1K, 5K, 24K, depende del navegador, puede haber un, puede haber, digamos, un límite, ¿vale?
Entonces mucha gente lo que hace es utilizar POST, pero está mal.
Está mal conceptualmente.
Está bien porque te soluciona el problema de que tú utilizas el cuerpo para hacer la query, pero conceptualmente está mal porque POST, el verbo POST, está pensado para crear un recurso, ¿vale?
Para crear un recurso en el backend.
Y esto lo que diríamos es que es, ¿cómo es?
A ver, idempotente, ¿no?
O sea, es básicamente es que el método GET es idempotente.
Esto quiere decir que tú lo puedes llamar tantas veces como quieras que siempre vas a estar recibiendo el mismo resultado y no vas a modificar nada en el servidor.
Pero POST no es idempotente.
Cada vez que tú llamas a un POST, se supone que se está creando un recurso.
Se supone porque hay gente que entiende que es más modificar, pero es crear un recurso, ¿vale?
Midu, ¿usar Astro con un CMS requiere una build cada vez que se cambien contenidos, por ejemplo, un título o una imagen?
Sí, no, depende porque Astro también puede tener un servidor y puedes estar sacándolo del servidor haciendo una llamada a la API.
O sea que sí, pero también se puede utilizar con un webhook, detectar cuando se hace cambios en CMS y hacer otro despliegue.
Bueno, total, la idempotencia.
El tema es que GET es idempotente.
Por más veces que tú lo llames, no se están creando recursos en el servidor y, por lo tanto, GET se supone que tú lo puedes cachear.
Puedes cachear el resultado porque no debería pasar nada.
No tienes que crear ningún recurso, es idempotente y está bien que lo puedas cachear.
En cambio, POST no lo deberías poder cachear porque se supone que POST, cada vez que tú lo llamas, estás creando un nuevo recurso
y, por lo tanto, no tendría sentido cachearlo porque lo que te debería devolver o, como sería el estado de las cosas, sería distinto.
Entonces, ¿qué es lo que pasa?
Como tenemos esta limitación por un lado de GET, pero que nos lo da POST, pero que al utilizar POST lo estamos utilizando semánticamente mal,
para eso tenemos QUERY.
¿Por qué?
Porque QUERY tendría todo lo bueno de GET en el sentido de que es idempotente,
pero también tendría lo bueno de POST porque podemos utilizar el CONTENTBODY, ¿vale?
Entonces, QUERY serviría para esos GETs que a día de hoy no podemos hacer como nos gustaría con el CONTENTBODY
y lo tendríamos con el POST.
¿Y si mejoramos el GET y ya?
Eso no se puede hacer así.
No se puede hacer así porque la web, internet y cómo son las cosas es muy complicado.
Es complicado en el sentido de que todo tiene que ser retrocompatible.
Si tú arreglas GET de alguna forma, el problema es que puede ser que te encuentres con un montón de problemas
de compatibilidades, que rompas cosas y tal.
Entonces, QUERY sería como un GET con CONTENT, totalmente.
GET versión 2 y ya está, ¿no?
Entonces, sería como una versión 2.
Tendríamos algunas cosas también que se podrían, ¿ves?
Podríamos preguntar si puede aceptar QUERY con un HEADER.
Aquí tendríamos un uso.
En este caso, pues, teníamos QUERY CONTAX y aquí nos va a decir,
le podemos pasar directamente aquí la QUERY.
Claro, aquí como podéis ver, tenemos un CONTENTTYPE que sería EXAMPLE QUERY,
pero aquí le estamos pasando a QUERY como que le podemos pasar un JSON,
como que le podemos pasar lo que nos dé la gana.
Y aquí tendríamos la respuesta, ¿vale?
Le podríamos pasar lo que queráis.
Obviamente, ¿cuál es el problema?
Pues el problema es que normalmente con GET lo tendríamos que pasar directamente en la URL
y en cambio con QUERY lo podríamos hacer utilizando el CONTENTBODY.
Le podemos pasar SQL, JSON, lo que sea.
Aquí le está pasando un SELECT, pero entended que esto podría ser lo que queráis.
Además, una cosa que está bastante interesante, ¿veis?
Que aquí pone METHOD NAME QUERY, es SAFE, es SEGURO, IDEN POTENTE,
y aquí tendrías la especificación.
Yo creo que tiene bastante sentido porque pensad que GraphQL, por ejemplo,
GraphQL, que solo utiliza POST, está utilizando POST más que nada
para simplificar este problema que teníamos antes,
de que, claro, con el GET no podía pasar la información,
utilizas el POST para todo y ya está.
Pero creo que puede ser bastante interesante el hecho de tenerlo.
Para que entendáis esto, porque hay gente que dirá,
bueno, pero es que esto, esto de dónde han sacado y tal,
tened en cuenta que las conversaciones de utilizar este nuevo método QUERY
es bastante antiguas.
Mira, 2021, pero yo he visto conversaciones incluso de antes,
porque al final esto es un problema que hace mucho tiempo
que estábamos arrastrando en HTTP, que queríamos, bueno,
que todo el mundo pues quería y necesitaba.
Uno de los primeros nombres que querían utilizar era SEARCH,
y lo cambiaron por QUERY, creo que mucho mejor nombre,
QUERY, me gusta mucho, mucho, mucho más,
pero que ya lleva muchos, pero que muchos años hablando de esto,
ya está bastante rodado.
Si han hecho esta propuesta es porque está bastante cerca,
y no me extrañaría que dentro de dos, cinco años,
empecemos a ver cada vez más el hecho de utilizar el método QUERY
para construir un montón de APIs y cosas así,
en lugar del mítico GET, que se seguirá utilizando GET, seguramente,
y más por temas de retrocompatibilidad,
pero que poco a poco vamos a ir viendo más como algunas APIs
incluso te ofrecen la posibilidad de utilizar este método QUERY
para que le puedas pasar por el body de una forma mucho más sencilla
y sin necesidad de crear un recurso
el hecho de poder recuperar cualquier información.
O sea, que está bastante bien.
QUERY suena feo, deberían ponerle AD HONOREM, totalmente, ¿no?
Así que ahí tenemos una de las grandes novedades de HTTP.
Os digo, ¿qué lo hace especial?
Consulta con contenido en el cuerpo, que a diferencia del método GET,
que le tienes que pasar los parámetros de la consulta en la URL,
lo cual lo puede hacer ineficiente, limitado por longitud.
El método QUERY, que va a ser nuevo,
solo puedes pasar por el content body como se hace con el POST.
Seguro e idempotente por defecto,
al igual que GET, QUERY es idempotente,
o sea, que es un método que significa que el estado de los recursos
a los que se dirigen no los cambia,
no los modifica, no está creando nuevos recursos,
y por lo tanto se puede cachear,
y esto hace que sea una alternativa a POST,
porque a día de hoy muchos sistemas están utilizando POST,
porque GET no puedes pasarle el content body,
y ya lo tendrías.
Pero claro, el problema de POST es que no lo puedes cachear,
no es idempotente y te puede traer estos problemas.
Ahí lo tenéis, ¿eh?
Todavía no está aprobado.
Es una propuesta, pero está bastante trabajada,
bastante adelantada,
y yo creo que está muy cerca de ser aprobada.
O sea, para que tengas en cuenta,
más que una propuesta es un draft.
Son dos cosas diferentes.
Una propuesta sería cuando se propone algo,
pero esto más que propuesta,
estamos hablando de un draft.
O sea, estamos hablando de un borrador sobre el que se está trabajando,
ya está en el grupo de trabajo,
y esto, la idea es que antes,
esto está para publicar, ¿vale?
Esto está para publicar,
se va a hacer alguna discusión,
pero ya se ha estado hablando de esto.
O sea, no es una cosa que sea totalmente nueva.
Y la idea es que esto está listo
para ser añadido a la especificación,
para que lo sepáis.
¿Está iniciando?
No está iniciando, ¿eh?
De hecho, aquí en los enlaces,
aquí lo tenéis, ¿eh?
En este apéndice,
aquí tenéis todas las veces que se ha estado hablando
sobre este tema,
que se han hecho el rephrasing,
que se han hecho un montón de cosas,
y podéis alucinar desde el 2021
que ya están trabajando, ¿eh?
O sea, en el apéndice ya podéis ver
todos los enlaces de todo lo que se ha discutido,
y no es una cosa que ahora,
de repente, estén hablando,
sino que ya lleva bastante, bastante tiempo.
De hecho, creo que había visto,
incluso de más tiempo,
más allá del 2021, ¿eh?
Así que nada,
que ya hace mucho tiempo,
yo creo que lo vais a tener por ahí cerca,
solo que lo sepáis y que os suene,
que lo sepáis.