Ver la versión completa : [Ayuda] querystrings formados por barras
akualung
13/07/2011, 13:32
hola. Tengo una duda a ver si me podeis ayudar a resolverla.
A veces he visto urls donde, el querystring, en vez de estar formado de la forma normal, que es http://www.foobar.com/index.php?campo1=valor1&campo2=valor2&campo3=valor3 etc etc, está formado por barras, o sea http://www.foobar.com/index.php/valor1/valor2/valor3...
Cómo se llaman este tipo de querystrings? Para qué sirven? Los crea automáticamente el servidor, o los ha de crear manualmente el desarrollador web de la aplicación?
Perdonad si algunas de las anteriores preguntas no tienen mucho sentido, si supiera un poco más qué utilidad tiene un querystring así (o al menos si tiene algun nombre para buscar yo la información en el google) podría hacer preguntas más coherentes.
Creo que en el ciclo de informática explicaron una vez algo de este tema, pero en esa época estaba a la vez currando por las noches y no me enteraba de la misa la mitad.
Gracias de antemuslo :brindis:
Cómo se llaman este tipo de querystrings? http://en.wikipedia.org/wiki/Clean_URLs
Para qué sirven? En la wikipedia explican algunas de las razones. Básicamente, son más fáciles de escribir para el usuario. Por ejemplo, se usan en las Wikis. ¿A que es más fácil como usuario escribir "http://es.wikipedia.org/wiki/Madrid" que acordarte de "http://www.wikipedia.org/index.php?action=view&language=ES&article=Madrid"?
Los crea automáticamente el servidor, o los ha de crear manualmente el desarrollador web de la aplicación? No estoy seguro de entender bien esta pregunta porque no estoy seguro de a qué te refieres con "servidor" (¿servidor web? ¿servidor de aplicaciones? ¿framework web?). Básicamente, estas URLs las crea e interpreta el framework web que utilices. Crear una URL o la otra es cuestión de una función simple, y entender la URL es cuestión del framework específico que uses. Algunos frameworks incluso entenderán ambas URL y te darán a ti como desarrollador web la misma interfaz, que no dependerá de cómo el usuario haya accedido a la web, si con query strings tradicionales o con la las Clean URLs estas.
< - >
Por ejemplo, yo uso mucho cherrypy (framework web de Python). Esta es una función cherrypy típica para un servidor de algo como Twitter:
@webapp.template(templates.contentlist.contentlist )
def list(self, text=''):
session = model.Session()
contents = session.query(model.Twitt).order_by(model.Twitt.id .desc()).limit(10)
return dict(contents=contents, text=text)
A esta función da igual si la llamas con "http://servidor.com/list?text=Saludo" (con GET), "http://servidor.com/list" (y en el contenido del POST, text=saludo), o "http://servidor.com/list/Saludo" (con GET) Yo como programador del servidor no tengo que hacer ninguna diferencia, será el framework cherrypy el que se haya encargado de digerir todas las posibles formas de llamarla y hacer que todas sean iguales para mí, programador.
akualung
13/07/2011, 22:55
Cómo se llaman este tipo de querystrings? http://en.wikipedia.org/wiki/Clean_URLs
Para qué sirven? En la wikipedia explican algunas de las razones. Básicamente, son más fáciles de escribir para el usuario. Por ejemplo, se usan en las Wikis. ¿A que es más fácil como usuario escribir "http://es.wikipedia.org/wiki/Madrid" que acordarte de "http://www.wikipedia.org/index.php?action=view&language=ES&article=Madrid"?
Los crea automáticamente el servidor, o los ha de crear manualmente el desarrollador web de la aplicación? No estoy seguro de entender bien esta pregunta porque no estoy seguro de a qué te refieres con "servidor" (¿servidor web? ¿servidor de aplicaciones? ¿framework web?). Básicamente, estas URLs las crea e interpreta el framework web que utilices. Crear una URL o la otra es cuestión de una función simple, y entender la URL es cuestión del framework específico que uses. Algunos frameworks incluso entenderán ambas URL y te darán a ti como desarrollador web la misma interfaz, que no dependerá de cómo el usuario haya accedido a la web, si con query strings tradicionales o con la las Clean URLs estas.
< - >
Por ejemplo, yo uso mucho cherrypy (framework web de Python). Esta es una función cherrypy típica para un servidor de algo como Twitter:
@webapp.template(templates.contentlist.contentlist )
def list(self, text=''):
session = model.Session()
contents = session.query(model.Twitt).order_by(model.Twitt.id .desc()).limit(10)
return dict(contents=contents, text=text)
A esta función da igual si la llamas con "http://servidor.com/list?text=Saludo" (con GET), "http://servidor.com/list" (y en el contenido del POST, text=saludo), o "http://servidor.com/list/Saludo" (con GET) Yo como programador del servidor no tengo que hacer ninguna diferencia, será el framework cherrypy el que se haya encargado de digerir todas las posibles formas de llamarla y hacer que todas sean iguales para mí, programador.
Hola, juanvvc, gracias por contestar. Con lo de "servidor" me refería, por ejemplo, al Apache mismo, que es un servidor web, no? (o, más específicamente, un servidor de HTTP).
Esta mañana le he preguntado al profesor del curso de php que estoy haciendo, y me ha contestado que, según recuerda, es un tipo de "querystring" más antiguo que el que se usa actualmente (el que consiste de pares nombre=valor separados por andpersands) y que a menudo se utilizan para que en el querystring solo se vean los valores de las variables que se envían por get, pero sin que vean los nombres, y así se le pone un poco más dificil al que quiera intentar romper la seguridad de tu aplicación web. Si eso es cierto o solo una paranoia suya, eso ya es algo que ignoro :)
En el desarrollo web actual ya no atacas directamente al apache, sino que utilizas un framework (librería PHP, si prefieres) intermedio que es el que hace el cambio entre parámetros GET/loquesea y lo que recibe tu programa PHP.
La historia que te ha contado el profesor me da que es parcialmente inventada :)
akualung
13/07/2011, 23:47
En el desarrollo web actual ya no atacas directamente al apache, sino que utilizas un framework (librería PHP, si prefieres) intermedio que es el que hace el cambio entre parámetros GET/loquesea y lo que recibe tu programa PHP.
La historia que te ha contado el profesor me da que es parcialmente inventada :)
Hombre, es que el tio en cuestión es de estos informáticos veteranos que empezaron en el oficio hace la ostia y la verdad es que en algunas cosas que explica se le nota que le gusta hacer las cosas un poco a la antigua. De hecho, él dice que prefiere seguir maquetando las páginas web con tablas, por mucho que se hable de usar divs y posicionarlos a base de floats, etc.
Bueno, pero no te quedes con la idea de que http://www.foobar.com/index.php/valor1/valor2/valor3 es "a la antigua", que estoy por apostar algo a que no es así :)
Hombre, es que el tio en cuestión es de estos informáticos veteranos que empezaron en el oficio hace la ostia y la verdad es que en algunas cosas que explica se le nota que le gusta hacer las cosas un poco a la antigua. De hecho, él dice que prefiere seguir maquetando las páginas web con tablas, por mucho que se hable de usar divs y posicionarlos a base de floats, etc.
Yo tambien soy informatico veterano :p y no cuento milongas de esas. Lo que le pasa a tu profe (a tu profe y a cualquiera de nosotros en ese caso) es que él usa su método porque o bien no le ve ventajas hacerlo de laotra manera o no entiende bien como se hace de la otra manera. No solo en lo que te he puesto en negrita, si no en casi cualquier cosa.
Pej, a mi no me gusta usar ningun tipo de Framemork para programar en PHP. He probado Symfony y Tigermouse y PARA MI me resulta mas comodo no usarlos y programar yo lo que necesito y/o usar las funciones/clases que ya tengo hechas. Las ventajas que me proporciona el usar esos Framework no me convencen.
Si tu profe sabe usar bien CSS, me estraña que prefiera maquetar con tablas a hacerlo con DIV's. Mas que nada porque hacer tablas para todo hace que el código sea dificil de mantener y de volver a usar. A menos que tu profe use solo el modo diseñador del dreamweaver ( entonces ya sabemos porque le gustan las tablas :) )Aunque si da PHP me estrañaría esto ultimo.
En cuanto al tema del hilo... el compañero juanvvc ya lo ha explicado todo muy bien :D
le he preguntado al profesor del curso de php que estoy haciendo, y me ha contestado que, según recuerda, es un tipo de "querystring" más antiguo que el que se usa actualmente
tu profesor se refiere al PATH_INFO, creo que se llamaba. no va desencaminado ... este tipo de url son url generadas automaticamente por los frameworks modernos automaticamente, y que meten los parametros dentro del PATH_INFO.
el path_info antiguamente se usaba a pelo para hacer eso mismo, por eso tu profe lo recuerda como algo antiguo, pero ya te digo que ahora es lo mismo pero en lugar de a pelo lo generan los frameworks directamente.
la hacen asi, en el PATH_INFO porque "como efecto colateral" se generan lo que bien te han dicho, url limpias que a los buscadores les mola para el tema de SEO. aunque supongo que los frameworks decidieron revivir el antiguo PATH_INFO precisamente por lo de las url limpias.
Aiken
ZeNiTRaM
14/07/2011, 18:03
Ahora no se lleva el PATH_INFO sino el URL Rewrite de Apache:
http://httpd.apache.org/docs/2.0/misc/rewriteguide.html
Basicamente con esto puedes hacer que
http://miweb.com/pagina2/noseque.html
el servidor lo "traduzca" por algo como
http://miweb.com/index.php?s1=pagina2&s2=noseque
o incluso
http://miweb.com/index.php?algo=pagina2/noseque
Luego en PHP tu recibes la peticion como si fuera la segunda o la tercera petición y actuas en consecuencia. Eso si, Apache no te reescribe las URLs y te las cambia por las "bonitas" en tu HTML, todos los links que tengas vas a tener que ponerlos a mano con el formato bonito.
Pej, a mi no me gusta usar ningun tipo de Framemork para programar en PHP. He probado Symfony y Tigermouse y PARA MI me resulta mas comodo no usarlos y programar yo lo que necesito y/o usar las funciones/clases que ya tengo hechas.
mentiroso, si que te gusta trabajar con un framework, lo que pasa que usas el tuyo propio ("usar las funciones/clases que ya tengo hechas") ;)
Aiken
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.