Estos vídeos así de noticias de lo último que está saliendo, novedades, temas de actualidad que se están hablando son muy buenos, lo mantienen a uno informado
Uno de los casos más útiles que conozco es para consultas geoespaciales, los polígonos ni cagando caben en un GET y el POST es la solución pero deja mal sabor de boca.
@@fabioalfonso2144 Es de un vídeo que sacó midu sobre ofertas de trabajo y hay uno que te dice lo que ocupas pero pone esa palabra que resumidamente es que no te van a pagar
Yo he visto APIS que ya pasan body a peticiones tipo GET. Aparentemente lo único que lo prohibe es el cliente que se use para hacer las peticiones no permita enviar datos. Es completamente salido de todos los estándares, pero si tu backend lo soporta se puede preguntar por el body de una petición GET.
Lo hacen para filtros complicados. Por exemplo si hay 17 input en la pagina web, envier una get con 17 query parameters se ve feo. Prefieren una get /data con un body json con 17 parametros. Yo apruebo esa solucion es mas elegante y facil de implementar
FastAPI: Query(min_length=5, max_length=15): Utiliza la clase Query para definir validaciones en el parámetro de consulta. En este caso, category debe tener una longitud mínima de 5 caracteres y máxima de 15 caracteres. Así cuando se usa: GET /movies/?category=Sci-Fi. La función get_movies_by_category filtrará las películas que tienen la categoría "Sci-Fi" y devolverá una lista de esas películas. def get_movies_by_category(category: str = Query(min_length=5, max_length=15)) -> List[Movie]:
ostia en 5:09 con un webhook en astro detectar cambios y hacer despliegue estaria guai una clase de esto! lo dejas ir como quien no dice nada y en una frase dices mucho xD idempotente! ;)
Esto estará genial para sistemas con machine learning, para solicitar predicciones a un modelo idealmente se haría un GET pero no puedes mandarle una imagen binaria en un queryparam sin reventar el límite, así que todo se envía por POST a pesar de no ser lo semánticamente correcto
Apoyo totalmente esta propuesta. de verdad que a veces es muy incomodo tener que usar POST para hacer una petición que podría ser un GET si no fuera porque la url queda por fuera del limite del longitud
Habria que forzar el no-cache para datos dinamicos (que no se mantienen de la misma forma en el tiempo) consultados con QUERY? Por defecto, cacheables. Pequeña desventaja.
No he visto todavía el vídeo, pero, a todos aquellos que no entienden para qué proponen esto... ¿Núnca habéis oído hablar de los POST consultivos? No hay que haber trabajado 40 años de desarrollador web para saber que se estaba haciendo uso 'semánticamente hablando' incorrecto puesto que no había otra solución. Esto tiene muy buena pinta.
Me parece un acierto. GET quedaría para los recursos a los que se puede acceder por una url o identificador único del recurso, o bien para todos, y query para uno o un subconjunto de recursos que quedan delimitados por uno o más parámetros que se pasarían en la "query string". ¡Pero si te lo está diciendo la propia jerga! Query. Pues todo el sentido.
Desde cuándo no se pueden enviar bodies con GET o con cualquier otro método, qué RFC lo prohíbe? La caché no debería hacer caso a las headers de caché que precisamente están para eso?
Buen video midu como siempre, me gustaría preguntarte a la hora de diseñar una página antes de ir a figma qué lugar es bueno para ver ejemplos de diseño web/mobile revise behance pero cuál otro me recomiendas?
En el caso de Google (y muchisimos otros la verdad), no lo veo muy util ya que el hecho de que sea GET significa que puedes poner en favoritos la URL, y eso te llevará a la busqueda adecuada. Si la información está en el body, lo unico que puedes poner en favoritos es la URL sin query params, que no te sirve para nada... A efectos teoricos, GET no debería modificar nunca nada, pero a efectos prácticos, no sería la primera vez que veo a alguien usar un GET para insertar datos en una base de datos... así que es idempotente hasta que algún iluminao decide que no lo sea xd
Lo de GET para insertar datos es peligroso porque te pueden hacer el ataque ese del link donde te redirige a esa URL y hacen que hagas cosas que no querías
@@codingneko generalmente si funciona así, get es idempotente hasta que se usa mal, nada nuevo bajo el sol. Query no lo veo para cosas de frente al usuario sino que para las que pasan por atrás actualmente el problema de get es que los params si mal no recuerdo no son seguros
@@mm.786 los params son seguros siempre que no los uses para estupideces... la gracia de los params precisamente es que son visibles por el usuario... cuando la gente dice que get no es seguro, se refieren a eso mayormente. La cosa es que si tienes que transmitir datos sensibles, entonces si deberías usar el body, pero en la mayoria de casos en los que se transmiten datos sensibles, es adecuado usar POST. Cuando alguien hace log-in, por ejemplo, POST es correcto porque estás creando una sesión.
Suena a mi muy buena la propuesta. El nombre Query de la peticion HTTP me suena mejor que Search porque estas buscas unos datos en la base de datos con criterios de busquéda definidos (query against DB/ database). search ya sabes el resultado y puede que haces un filtro simple o complejo. Por otro lado, GET y POST por definicíon son muy diferentes. para qué introducir muchos parametros en el cuerpo de la peticion HTTP GET si GET te envias el mas rapido posible vuestra respuesta.
Que cómico que estoy programando una aplicación con gestión de una API bancaria. Y hace poco me equivoqué en el método, coloqué GET en vez de POST para enviar la informaión. Pero coloqué el body con todos los datos correctos y me dije a mí mismo... "Mí mismo, debería haber una alternativa rápida en este caso sin tener que declarar. Algo que simplemente vaya directo."
Trato de suscribirme desde venezuela y me dice que los metodos de pago no estan disponibles para mi pais. Incluso con VPN la tarjeta no pasa (aparte que es mas caro fuera de vzla).
suena genial. sería de mucha ayuda en las webapps u otro servicio de consumo en ese estilo, más cuando los frameworks muchas veces te crean urls largas. Yo he usado POST en ese sentido, más por no llenar la barra de direcciones, siento que es antiestetico poner la leyenda de la bruja azul en ese input de texto. Prefiero adjuntarlo en un body. Por cierto, existe el verbo "stream"?? digo, porque sí no, ya va siedo hora, digo, las los asistentes virtuales tardan en generar las consultas, así que estaría bueno...
esta muy bien lo que yo utilizo es una websocket para hacer algo parecido con elixir pero no es lo mismo un websocket tal vez consuma muchos recursos en JS o en PHP no seria tan escalable como un query
No entendi muy bien, yo con java spring boot en el backend coloco el @GetMapping() con el @RequestBody, no entiendo el problema de que no se pueda usar el body o hay algo que me estoy saltando (┬┬﹏┬┬)
porque el comentario tecnicamente de midu va mas por un lado de web, y no tanto en webservice, entonces esta visto desde esta perspectiva mas clasica, en el caso de webservice y apirest no te das cuenta de muchas cosas... xq tecnicamente es casi lo mismo dependiendo de la necesidad y el recurso que necesites modificar de la db o que vas a entregar...generalmente usas post cuando tenes que cargar contenido largo... jajaja
En el controlador puedes hacerlo, pero trata de crear una request GET con body, ya sea con RestTemplate, RestClient o Webclient y verás la restricción.
Es una buena noticia. Entiendo que conceptualmente este mal, pero siempre me ha parecido mas conveniente el utilizar POST en lugar de GET. Sobre todo en proyectos donde soy el único desarrollador.
Idempotencia es que al hacer la llamada dos veces, obtengas el mismo resultado que al haberla hecho una vez, y en este contexto, que también el estado del servidor sea el mismo en ambos casos. PUT crea recursos en el servidor, pero es idempotente, porque aplicarlo dos veces es lo mismo que aplicarlo una vez. POST usado para la creación de recursos, no es idempotente, porque aplicarlo dos veces usualmente crea dos recursos diferentes y aplicarlo una vez crea un solo recurso. Si usas el POST para hacer una query de graphql, POST en este caso será idempotente.
Creo que hay algo similar en PHP así como usamos $_GET/POST se usa $_REQUEST pero normalmente se usa para recibir datos desde el cliente, creo que eso nos genera algo así como un efecto mándela XD
Yo uso POST para poder mandar un montón de datos. No es una buena práctica, pero cuando he tenido que mandar muchísima información, no me preocupo por que no funcione.
Qué hay de compartir URLs? Copiar y pegar una url de Google Maps por ejemplo, dejaría de funcionar. Otra cosa. Eso quiere decir que ahora sería HTTP 1.2?
No rompería con versiones anteriores de HTTP, así que no sería necesario otra versión del standard, es una característica de tipo "opt-in", puedes decidir entre utilizarla o no, no es algo obligatorio o impuesto
Y por qué es tan importante el método de request? el modelo get, post, put y delete no se ajustan necesariamente a todas las aplicaciones, la diferencia entre put y post no está muy claro si es tan relevante, en fin, para mí podrían ser un simple header `http-method: get` y ya, o que cada aplicación maneje los requests como le parezca.
deberian agregar la opción en html para cambiar de metodo. no se para que tantos metodos http si desde un link solo se puede hacer get. salvo que le reemplaces el comportamiento con js claro pero eso dificulta otras cosas como los web crowlers los lectores de pantalla etc.
Y si solo dejan el metodo POST y nada mas? Y lo que haga dentro depende del backend, puedes hacer consultas en una ruta, crear un recurso en otra, y eliminar un recurso en otra...
Yo propongo el metodo Mixy, envias datos poco relevantes por url y privados en el body, por ejemplo en la url la categoria donde va a buscar y en el body que buscar y datos de usuario o session. 🤣
mmmmm la verdad que no... no lo quiero..... LO NECESITO !!!!!! jajajajja Miduuu me gustaria que refutes el por que los creadores de SQL, jamas se les ocurrió crear la sentencia "WHERE ALL" para los casos de modificaciones de registros evitando olvidarte el WHERE y así no hacer macana cuando hacemos un UPDATE o DELETE... abrazo grande!
4:30 idempotente no creo que sea el término, eso sería si recibieses siempre el mismo resultado y no es así, una query puede devolver otro resultado por ejemplo porque ha pasado el tiempo. No? Get es para obtener recursos, post es para empaquetar una nueva entidad, así lo entiendo yo
@@ElPolemista Imagino que se refiere a que enviando la misma información, se recibe siempre el mismo resultado, al igual que cua do haces un PUT. Por ej, al hacer un POST, misma información produce diferentes resultados en cada llamada que se hace.
@@mindOf_L si lo entiendo, pero es que idempotente no es eso. Las operaciones de lectura no son "per se" idempotentes. De la misma forma que un post/put si lo puede ser.
Pero si post no modifica el estado del recurso si no quieres. Yo imaginaba que iba a ser algo como streaming. Me parece que este nuevo request no ayuda mucho.
Encuentro engorroso usara get no por el método mismo, sino por lo inseguro que es, debido a esto tienes que construirle muchos métodos de seguridad al rededor lo cual implica tiempo solo para enviar datos! es algo que no se puede obviar por que la seguridad es importante pero no deja de ser tedioso, me recuerda un poco a esos videos de protege el lamborgini y si sobrevive te lo quedas.
Query me parece perfecto como nombre. GET = dame un recurso. QUERY = materializa esta petición. O sea, tengo una pregunta, resuelvela. En cambio "get" es más como, sé lo que quiero exactamente, dámelo.
Me pregunto si no sería mejor en vez de crear un nuevo método, que el method:”GET” sea la v1, luego si quieres usar la v2 sería method:”v2/GET” o algo así
No consiste en hacer una consulta de SQL como método de HTTP sino encontrar una mejor manera de definir los parámetros de búsqueda, de ahí extraer los parámetros que puedan ser usados en SQL o NoSQL incluso.
Tu lo has dicho, "ejemplo", puede ser cualquier tipo de contenido, como si quieres pasar un buffer de bytes en binario con "application/octet-stream", como un json con "application/json", lo que tu quieras :p En el Draft el content-type se muestra como "example/query"
son implementaciones, no significa que debas hacerlo asi, el documento establece formas de usarlo y lo que dice @josesanc673 explica bien lo que se busca hacer.
Creería que es mas simple y menos costoso de cachear el URL ya que el url es el hash que cachear el url y body ese es un posible problema que tendría ese método query Probablemente pueda utilizar algún cifrado como un sha, pero sería importante tenerlo presente
@@FerminDevMobile lo que trato de decir es que parte del proceso del caching utiliza el url como base para ello y no suele tener en cuenta el body Generalmente si se usa el body para cambiar una búsqueda el url que es esa llave de referencia para el caching no cambiaría Esa es una de las razones para utilizar en los parámetros un cursor (un hash largo que representa la query o una referencia de la query que utiliza un cursor) O quizás ha de usar algo más para saber que esta cacheando como tal
El problema es que va a tener que modificarse todos los software que hacen uso de peticiones no creo que se hagan asi nomas lo dudo se va a tener que cambiar código fuentes y hasta kernel de sistemas operativos asi que lo dudo midu lo veo verde
no están deprecando nada, implementaran un "nuevo" método para que en las implementaciones de API nuevas o existentes no tengan que usar POST para una peticion de tipo consulta o un GET con queryparams.
@@iamsteeveme doctor sin animos de responder mal quien esta hablando de “deprecacion” ??? O te haz confundido a quien responder por ello te disculpo pero otro lado creo que debes aprender un poco mas de informatica saludos.
POST es como el Anillo único , un solo verbo para manejarlos a todos yo soy de la vieja escuela no uso get,ni put, ni delete solo post. nada de andar facilitándole la vida a los men in the meddle. incluso el nombre del método también debería ir en el post por seguridad. en cuanto a la semántica cada quien que tenga la suya propia no veo problema en que arreglen get para que acepte un body, si que traería algún problema de retro compatibilidad sobre todo si alguien quisiere usar un api mas antigua usando un método nuevo pero no veo mal que los programadores junior pasen un poco de trabajo cometiendo esta clase de errores 👹😈jajajajajaja 👹😈
Estos vídeos así de noticias de lo último que está saliendo, novedades, temas de actualidad que se están hablando son muy buenos, lo mantienen a uno informado
SIEMPRE he echado en falta la existencia de un método así jajaj
Uno de los casos más útiles que conozco es para consultas geoespaciales, los polígonos ni cagando caben en un GET y el POST es la solución pero deja mal sabor de boca.
" Query suena feo Deberían de ponerle ad honorem " 😂😂😂 mori
@@AbrahanAcero me das contexto?
@@fabioalfonso2144 es de un video pasado donde analizaba ofertas de trabajo, y usaban ese termino para contratar a programadores pero sin pagarles
@@fabioalfonso2144 Es de un vídeo que sacó midu sobre ofertas de trabajo y hay uno que te dice lo que ocupas pero pone esa palabra que resumidamente es que no te van a pagar
El contexto es tener concentración. @@fabioalfonso2144
Yo he visto APIS que ya pasan body a peticiones tipo GET. Aparentemente lo único que lo prohibe es el cliente que se use para hacer las peticiones no permita enviar datos. Es completamente salido de todos los estándares, pero si tu backend lo soporta se puede preguntar por el body de una petición GET.
si haces eso puedes tener problemas con cache y proxies ya que ignoran el body si es una peticion GET
Lo hacen para filtros complicados. Por exemplo si hay 17 input en la pagina web, envier una get con 17 query parameters se ve feo. Prefieren una get /data con un body json con 17 parametros. Yo apruebo esa solucion es mas elegante y facil de implementar
Juraría que ya ví peticiones QUERY por algún lado, igual pensé que ya estaba, pero bue
@@marliote me suena a GraphQL
Blazor
FastAPI: Query(min_length=5, max_length=15): Utiliza la clase Query para definir validaciones en el parámetro de consulta. En este caso, category debe tener una longitud mínima de 5 caracteres y máxima de 15 caracteres. Así cuando se usa: GET /movies/?category=Sci-Fi. La función get_movies_by_category filtrará las películas que tienen la categoría "Sci-Fi" y devolverá una lista de esas películas.
def get_movies_by_category(category: str = Query(min_length=5, max_length=15)) -> List[Movie]:
Yo te juro que también lo leí hace tiempo pero estoy tan empanado que seguro fue cerca del 14 de setiembre cuando lo publicaron.
@@esde3210 jQUERY
siempre que traiga mas tipos de respuestas junto con ella para mi será una bendición
ostia en 5:09 con un webhook en astro detectar cambios y hacer despliegue estaria guai una clase de esto! lo dejas ir como quien no dice nada y en una frase dices mucho xD idempotente! ;)
Pues claro, a mi me ha tocado hacer peticiones POST para enviar varios filtros en formato JSON y poder obtener datos 😅 esta mejora la necesitamos
a mi tambien , la he usado en el trabajo y en personal tambien
para los que ya vieron el metodo query en algun sitio, la primera publicacion se hizo en 2021-11-09
Esto esta buenisimo!!! Cuanto tiempo que no veiamos actualizaciones de este tipo! Ojala prospere y lo podamos usar pronto!
Esto estará genial para sistemas con machine learning, para solicitar predicciones a un modelo idealmente se haría un GET pero no puedes mandarle una imagen binaria en un queryparam sin reventar el límite, así que todo se envía por POST a pesar de no ser lo semánticamente correcto
Propongo en LATAM llamar el método "ALO" y en España "DIGAME"
Sería un problema de seguridad, porque podrías responder "soy yo" y siempre te dejarían entrar donde quisieras 😂
@@xavimb eso sería para autenticación. Método QUIÉN, respuesta YO.
Ya era hora, años pidiendo esto
Está muy buena la propuesta para el QUERY
tendremos nuestras URLs limpias al mismo tiempo que jalamos del back las cosas a nuestro gusto
Entonces con Query se usa en query string de la URL y luego metes también en el body como en un POST? Curioso
Apoyo totalmente esta propuesta. de verdad que a veces es muy incomodo tener que usar POST para hacer una petición que podría ser un GET si no fuera porque la url queda por fuera del limite del longitud
Habria que forzar el no-cache para datos dinamicos (que no se mantienen de la misma forma en el tiempo) consultados con QUERY? Por defecto, cacheables. Pequeña desventaja.
No he visto todavía el vídeo, pero, a todos aquellos que no entienden para qué proponen esto... ¿Núnca habéis oído hablar de los POST consultivos? No hay que haber trabajado 40 años de desarrollador web para saber que se estaba haciendo uso 'semánticamente hablando' incorrecto puesto que no había otra solución. Esto tiene muy buena pinta.
Me parece un acierto. GET quedaría para los recursos a los que se puede acceder por una url o identificador único del recurso, o bien para todos, y query para uno o un subconjunto de recursos que quedan delimitados por uno o más parámetros que se pasarían en la "query string". ¡Pero si te lo está diciendo la propia jerga! Query. Pues todo el sentido.
Desde cuándo no se pueden enviar bodies con GET o con cualquier otro método, qué RFC lo prohíbe? La caché no debería hacer caso a las headers de caché que precisamente están para eso?
Buena alternativa, y no choca con el get porque se puede seguir utilizando y ya para consultas grandes ahí si usar query
Buen video midu como siempre, me gustaría preguntarte a la hora de diseñar una página antes de ir a figma qué lugar es bueno para ver ejemplos de diseño web/mobile revise behance pero cuál otro me recomiendas?
En el caso de Google (y muchisimos otros la verdad), no lo veo muy util ya que el hecho de que sea GET significa que puedes poner en favoritos la URL, y eso te llevará a la busqueda adecuada. Si la información está en el body, lo unico que puedes poner en favoritos es la URL sin query params, que no te sirve para nada...
A efectos teoricos, GET no debería modificar nunca nada, pero a efectos prácticos, no sería la primera vez que veo a alguien usar un GET para insertar datos en una base de datos... así que es idempotente hasta que algún iluminao decide que no lo sea xd
Lo de GET para insertar datos es peligroso porque te pueden hacer el ataque ese del link donde te redirige a esa URL y hacen que hagas cosas que no querías
@@codingneko generalmente si funciona así, get es idempotente hasta que se usa mal, nada nuevo bajo el sol. Query no lo veo para cosas de frente al usuario sino que para las que pasan por atrás actualmente el problema de get es que los params si mal no recuerdo no son seguros
@@mm.786 los params son seguros siempre que no los uses para estupideces... la gracia de los params precisamente es que son visibles por el usuario... cuando la gente dice que get no es seguro, se refieren a eso mayormente. La cosa es que si tienes que transmitir datos sensibles, entonces si deberías usar el body, pero en la mayoria de casos en los que se transmiten datos sensibles, es adecuado usar POST. Cuando alguien hace log-in, por ejemplo, POST es correcto porque estás creando una sesión.
Suena a mi muy buena la propuesta. El nombre Query de la peticion HTTP me suena mejor que Search porque estas buscas unos datos en la base de datos con criterios de busquéda definidos (query against DB/ database). search ya sabes el resultado y puede que haces un filtro simple o complejo. Por otro lado, GET y POST por definicíon son muy diferentes. para qué introducir muchos parametros en el cuerpo de la peticion HTTP GET si GET te envias el mas rapido posible vuestra respuesta.
Te acabo de ver en la nerdearla y recién vuelvo a casa y me puse a ver un vídeo tuyo jajaj nos vemos mañana!
Pero con QUERY también se podrá pasar data viq query params? O estará limitado solo para pasar data por su body?
Ojo, se puede usar el body en cualquier verbo, incluso el GET. Está en la especificación del protocolo, solo que no es estándar.
Estoy cambiaría la manera en la que se hacen las peticiones a servicios GraphQL? 🤔
No entiendo, ¿por qué no mejor un GET 2.0 que se siga llamando GET pero con el content body?
Que cómico que estoy programando una aplicación con gestión de una API bancaria. Y hace poco me equivoqué en el método, coloqué GET en vez de POST para enviar la informaión. Pero coloqué el body con todos los datos correctos y me dije a mí mismo... "Mí mismo, debería haber una alternativa rápida en este caso sin tener que declarar. Algo que simplemente vaya directo."
Puedo empezar a jugar con eso ya? En proyectos acá míos de práctica y estudios claro
aun no lo aprueban
Si pasas los parámetros por body, la url deja de ser compartible, y en la mayoría de los casos es necesario
Trato de suscribirme desde venezuela y me dice que los metodos de pago no estan disponibles para mi pais. Incluso con VPN la tarjeta no pasa (aparte que es mas caro fuera de vzla).
se usa mucho en electrónica para micro controladores para IOT
En mi trabajo usamos muchos post como get, y siempre me ha incomodado eso 😂 está bueno
suena genial. sería de mucha ayuda en las webapps u otro servicio de consumo en ese estilo, más cuando los frameworks muchas veces te crean urls largas. Yo he usado POST en ese sentido, más por no llenar la barra de direcciones, siento que es antiestetico poner la leyenda de la bruja azul en ese input de texto. Prefiero adjuntarlo en un body.
Por cierto, existe el verbo "stream"?? digo, porque sí no, ya va siedo hora, digo, las los asistentes virtuales tardan en generar las consultas, así que estaría bueno...
esta muy bien lo que yo utilizo es una websocket para hacer algo parecido con elixir pero no es lo mismo un websocket tal vez consuma muchos recursos en JS o en PHP no seria tan escalable como un query
¿Este tipo de peticiones serían funcionales en webs estáticas?
Eso mejoraría bastante la forma de hacer reportes ?
No entendi muy bien, yo con java spring boot en el backend coloco el @GetMapping() con el @RequestBody, no entiendo el problema de que no se pueda usar el body o hay algo que me estoy saltando (┬┬﹏┬┬)
porque el comentario tecnicamente de midu va mas por un lado de web, y no tanto en webservice, entonces esta visto desde esta perspectiva mas clasica, en el caso de webservice y apirest no te das cuenta de muchas cosas... xq tecnicamente es casi lo mismo dependiendo de la necesidad y el recurso que necesites modificar de la db o que vas a entregar...generalmente usas post cuando tenes que cargar contenido largo... jajaja
tecnicamente es posible, pero va en contra del diseño de api rest
En el controlador puedes hacerlo, pero trata de crear una request GET con body, ya sea con RestTemplate, RestClient o Webclient y verás la restricción.
El fin de graphql? al poner parametros ya vas a poder pedir solo los datos que ocupas, no?
Era hora.
Se podra usar para hacer un login en lugar de usar POST?
si me uno a que tengo acceso, para ver si pongo a estudiar a mi hijo, le serviria los cursos?
y el tema del seo esta cubierto tambien ?
Es una buena noticia. Entiendo que conceptualmente este mal, pero siempre me ha parecido mas conveniente el utilizar POST en lugar de GET. Sobre todo en proyectos donde soy el único desarrollador.
Idempotencia es que al hacer la llamada dos veces, obtengas el mismo resultado que al haberla hecho una vez, y en este contexto, que también el estado del servidor sea el mismo en ambos casos. PUT crea recursos en el servidor, pero es idempotente, porque aplicarlo dos veces es lo mismo que aplicarlo una vez. POST usado para la creación de recursos, no es idempotente, porque aplicarlo dos veces usualmente crea dos recursos diferentes y aplicarlo una vez crea un solo recurso.
Si usas el POST para hacer una query de graphql, POST en este caso será idempotente.
Creo que hay algo similar en PHP así como usamos $_GET/POST se usa $_REQUEST pero normalmente se usa para recibir datos desde el cliente, creo que eso nos genera algo así como un efecto mándela XD
Yo uso POST para poder mandar un montón de datos. No es una buena práctica, pero cuando he tenido que mandar muchísima información, no me preocupo por que no funcione.
Qué hay de compartir URLs? Copiar y pegar una url de Google Maps por ejemplo, dejaría de funcionar.
Otra cosa. Eso quiere decir que ahora sería HTTP 1.2?
No rompería con versiones anteriores de HTTP, así que no sería necesario otra versión del standard, es una característica de tipo "opt-in", puedes decidir entre utilizarla o no, no es algo obligatorio o impuesto
Y por qué es tan importante el método de request? el modelo get, post, put y delete no se ajustan necesariamente a todas las aplicaciones, la diferencia entre put y post no está muy claro si es tan relevante, en fin, para mí podrían ser un simple header `http-method: get` y ya, o que cada aplicación maneje los requests como le parezca.
en .NET esto si es posible, sin ninguna dificultad. Entiendo que es mas por el lado de node?
deberian agregar la opción en html para cambiar de metodo. no se para que tantos metodos http si desde un link solo se puede hacer get. salvo que le reemplaces el comportamiento con js claro pero eso dificulta otras cosas como los web crowlers los lectores de pantalla etc.
Y si solo dejan el metodo POST y nada mas? Y lo que haga dentro depende del backend, puedes hacer consultas en una ruta, crear un recurso en otra, y eliminar un recurso en otra...
Es un asunto de usar la semántica correcta 😊
Yo propongo el metodo Mixy, envias datos poco relevantes por url y privados en el body, por ejemplo en la url la categoria donde va a buscar y en el body que buscar y datos de usuario o session. 🤣
mmmmm la verdad que no... no lo quiero..... LO NECESITO !!!!!! jajajajja
Miduuu me gustaria que refutes el por que los creadores de SQL, jamas se les ocurrió crear la sentencia "WHERE ALL" para los casos de modificaciones de registros evitando olvidarte el WHERE y así no hacer macana cuando hacemos un UPDATE o DELETE... abrazo grande!
4:30 idempotente no creo que sea el término, eso sería si recibieses siempre el mismo resultado y no es así, una query puede devolver otro resultado por ejemplo porque ha pasado el tiempo.
No?
Get es para obtener recursos, post es para empaquetar una nueva entidad, así lo entiendo yo
@@ElPolemista Imagino que se refiere a que enviando la misma información, se recibe siempre el mismo resultado, al igual que cua do haces un PUT. Por ej, al hacer un POST, misma información produce diferentes resultados en cada llamada que se hace.
@@mindOf_L si lo entiendo, pero es que idempotente no es eso.
Las operaciones de lectura no son "per se" idempotentes. De la misma forma que un post/put si lo puede ser.
miduve eso no vendrá http 2, es un RFC?
Según yo desde hace rato que se puede enviar body en un GET, otra cosa es que no lo hagamos ..... quizás mi memoria está fallando de todos modos
Pero si post no modifica el estado del recurso si no quieres.
Yo imaginaba que iba a ser algo como streaming.
Me parece que este nuevo request no ayuda mucho.
Por qué el logo de midu es el de VSCode al revés? 🤔
Esto como afecta a graphql, trcp
Encuentro engorroso usara get no por el método mismo, sino por lo inseguro que es, debido a esto tienes que construirle muchos métodos de seguridad al rededor lo cual implica tiempo solo para enviar datos! es algo que no se puede obviar por que la seguridad es importante pero no deja de ser tedioso, me recuerda un poco a esos videos de protege el lamborgini y si sobrevive te lo quedas.
Soy al único que le pasa que en next cuando pasas de npm run dev a prod se ve como con zoom?
ya hacía falta dio mio jaja hay muchos casos de uso en el que intentamos obtener algo pero hay que mandar un payload grandesito
That seems promising for LLM applications e.g. summarising content
El queryparans no necesariamente es cifrado, el body de un post snuy buen vídeo
Query me parece perfecto como nombre. GET = dame un recurso. QUERY = materializa esta petición. O sea, tengo una pregunta, resuelvela. En cambio "get" es más como, sé lo que quiero exactamente, dámelo.
Me pregunto si no sería mejor en vez de crear un nuevo método, que el method:”GET” sea la v1, luego si quieres usar la v2 sería method:”v2/GET” o algo así
El propio Midu lo menciona en el video, no hace sentido modificar GET a si sea a una version 2, ya que nadie migraria por temas de compatibilidad
@@FerminDevMobileclaro, lo que decía, es que en vez de modificar directamente el actual get, que saquen un v2/get. Como en los endpoints.
Ese ejemplo de pasar el SQL así a lo bruto me parece un tremendo agujero de seguridad
No consiste en hacer una consulta de SQL como método de HTTP sino encontrar una mejor manera de definir los parámetros de búsqueda, de ahí extraer los parámetros que puedan ser usados en SQL o NoSQL incluso.
Tu lo has dicho, "ejemplo", puede ser cualquier tipo de contenido, como si quieres pasar un buffer de bytes en binario con "application/octet-stream", como un json con "application/json", lo que tu quieras :p
En el Draft el content-type se muestra como "example/query"
De hecho puedes pasar sql por get y por post... 😅 Realmente no tiene nada que ver SQL, sino que puedes usarlo como post y se comporta como un get
son implementaciones, no significa que debas hacerlo asi, el documento establece formas de usarlo y lo que dice @josesanc673 explica bien lo que se busca hacer.
Pensé que había quedado claro de que era una representación de parametros de busqueda (para demostrar la bondad de QUERY) y no de un sql como tal
habla de la situacion con wordpress y wordpress engine
Creería que es mas simple y menos costoso de cachear el URL ya que el url es el hash que cachear el url y body ese es un posible problema que tendría ese método query
Probablemente pueda utilizar algún cifrado como un sha, pero sería importante tenerlo presente
Si todo el tiempo estoy llamando una api de paises que se que nunca van a cambiar, cual seria el punto de hacer cache solo de la url?
@@FerminDevMobile lo que trato de decir es que parte del proceso del caching utiliza el url como base para ello y no suele tener en cuenta el body
Generalmente si se usa el body para cambiar una búsqueda el url que es esa llave de referencia para el caching no cambiaría
Esa es una de las razones para utilizar en los parámetros un cursor (un hash largo que representa la query o una referencia de la query que utiliza un cursor)
O quizás ha de usar algo más para saber que esta cacheando como tal
Bienvenido a GraphQL :D
Cualquiera puede implementarlo aún si no se aprueba la propuesta, HTTP lo permite
rapido pero bien 🤘
se que no es muy correcto pero a veces he tenido que usar el post para obtener datos 😢
Vamos, está basado en GraphQL?
La completaría con que pueda usarse para hacer redirecciones.
Si no habré terminado usando get con body o post sin crear nada jajajajaja rest hace tiempo se durmió en los laureles
Jajaja si yo creo que vi esa petición hasta en una prueba que hice... Por eso decía que si ya no existía...
Esto sería genial para los server island de astro...
Por finn !!!
Yo solo uso post. Ahí envío un json con el verbo y con todos los parámetros que quiero 😬
Seria bueno que QUERY sea un verbo nativo en html, osea que se pueda usar sin necesidad de usar JS
Midu, el GET tiene el Body habilitado, aunque sea una practica absurda. Te lo permite.
Que piensas al respecto?
Es cierto. Por lo general, se ignora y ya. Pero estoy casi seguro de que algunos servidores se pueden configurar para aceptarlo y procesarlo.
Para luego ocupar get y post para todo 😅
literal, las personas somos animales de costumbres 🤣
si soy 😆
Yo le habría puesto GET2 okno😅
Lo que ahora no veo razón para usar get.
igual ya usaba post en todo por seguridad
El problema es que va a tener que modificarse todos los software que hacen uso de peticiones no creo que se hagan asi nomas lo dudo se va a tener que cambiar código fuentes y hasta kernel de sistemas operativos asi que lo dudo midu lo veo verde
no están deprecando nada, implementaran un "nuevo" método para que en las implementaciones de API nuevas o existentes no tengan que usar POST para una peticion de tipo consulta o un GET con queryparams.
@@iamsteeveme doctor sin animos de responder mal quien esta hablando de “deprecacion” ??? O te haz confundido a quien responder por ello te disculpo pero otro lado creo que debes aprender un poco mas de informatica saludos.
Lo que ya esta con post GET/POST se deja y se añade este nuevo metodo, donde estaria el problema?
Get con filtros ocultos 🎉🎉🎉
Bien explcado,
Si las urls son inseguras imagino un body get boom
POST es como el Anillo único , un solo verbo para manejarlos a todos yo soy de la vieja escuela no uso get,ni put, ni delete solo post. nada de andar facilitándole la vida a los men in the meddle. incluso el nombre del método también debería ir en el post por seguridad. en cuanto a la semántica cada quien que tenga la suya propia no veo problema en que arreglen get para que acepte un body, si que traería algún problema de retro compatibilidad sobre todo si alguien quisiere usar un api mas antigua usando un método nuevo pero no veo mal que los programadores junior pasen un poco de trabajo cometiendo esta clase de errores 👹😈jajajajajaja 👹😈
midu peralta el que se tira un pedo y salta
El fin de graphql😂
Esta perfecto para inyecciones SQL
Hasta suena más bonito, otro beneficio es que no le agrega más letras al CRUD😂
Aunque quedaría bien CQRUD.
Read suena a “as-is” y a “recurso único”
Query suena a “filter”, a “listado”
Read aplica para un recurso o muchos recursos (lista o paginado)
QUD, si tenemos en cuenta que ese hace los dos jajaja
sigue siendo read solo mandando los parametros de otra forma
QRUD 🥵
Es como graphql que con solo un endpoint se hace todo