Uso de diferentes tipos de URLs en aplicaciones Web

[mamcx]

Precisamente.

Una url de forma Cliente?Esto=1&Aquello=2

PUEDE que invoque una accion dinamica. Como crear una cuenta.

Ahora imagina a los spider navegando la pagina y !puff! "clikean" esa URL. Y se van a crear una cuenta... y son varios spider en varias pasadas, y le dan submit al rollo, y devuelve error y se queda en un ciclo...

Ese es el problema que tiene un spider: Que hacer con las URLS? Invocan acciones dinamicas o estaticas?

En cambio:

Cliente/Esto/Aquello

Luce como algo ESTATICO.

Fijate que la mayoria de los sitios web que usan funciones (internas) realmente presentan contenido estatico. O sea, se pudieran haber hecho a mano y quedarian igual.

Por ejemplo, el inicio, los faqs, la info de los productos, etc... realmente pueden presentarse en forma estatica.

No es tanto que hayan Urls "limpias" sino Urls con un sentido y proposito claro.

[roman]

Empezado por mamcx

Una url de forma Cliente?Esto=1&Aquello=2

PUEDE que invoque una accion dinamica. Como crear una cuenta.

Pues justamente, es lo que no queda claro. Porque entonces parece que el problema es en el uso que le demos a las formas regulares de urls. Una petición GET no debería estar haciéndola de POST. La url (petición GET) debe representar un documento en la web, esto es, algo tangible, no una acción.

// Saludos

[*Emilio*]

Yo creo que aquí se están mezclando los usuarios y los buscadores.

Empezando por los usuarios, no encuentro lógico hacer algo para que les parezca menos complicado (ufff, que monstruosidad acabo de decir), bien, me refiero a que hay que abolir los malos hábitos, es de todos los usuarios conocido que una url lleva tres w delante, cosa totalmente falsa, www es un subdominio igual que cualquier otro, por ejemplo http://neftali.clubdelphi.com sería una url totalmente válida pero que ocurre con ello, que los usuarios tienden a pensar que debe ser http://www.neftali.clubdelphi.com y que hacemos, pues que para tener un subdominio realmente tienes que crear dos, uno para el que realmente quieres tener y otro para usuarios con conceptos erroneos, y que hacemos realmente con ello, alimentar su error.

¿Qué quiero decir con esto? sencillamente que si un usuario tiene que teclear la url http://www.clubdelphi.com/fichero.ph...otro=otrovalor creo que le estamos haciendo un favor, para que continuar engañándole con carpetitas?

En cuanto a los buscadores, ellos saben muy bien y si no lo saben vaya buscador será, desmenuzar url y sus parámetros, está claro que el primer parámetro es el más importante para el buscador, no obstante por supuesto no omite los segundos parametros, vease un ejemplo en esta búsqueda en google.

Después de este extenso hilo que ni dec imaginaba que daría para tanto cuando lo inicio, me quedo con el mal sabor de boca al no haber realmente escuchado una buena razón por la cual debo hacer uso de otro tipo de url.

En fin, igual el hilo sigue y todavía sacamos algo en claro.

[mamcx]

Obviamente que un argumento del tipo "si no lo hacemos asi nos morimos" no va a haber, y menos en tonterias informaticas...

Pero ya que de tonterias informaticas vivimos pues...

Yo creo que aquí se están mezclando los usuarios y los buscadores

Ni tanto. Recuerda que un buscador, como google, esta enfocado hacia los usuarios.

Ponte en las zapatillas de un ingeniero de Google o MSN. Tiene que usar formas indirectas para evaluar una pagina.

¿Tiene buenos chistes?. No. Los buscadores no saben reirse. Paila por ese lado

¿Tiene argumentos logicos?. No. La logica de un ordenador no es la de un humano. Tampoco se puede

¿La fotos son bonitas?. No. No saben que es bonito

Nada de eso sirve. Pero si sirve:

¿Cumple con estandares? Si. Eso se puede chequear. Indirectamente se deduce un mejor diseñador/programador web, lo que implica una empresa contratante mas enfocada

¿Tiene buena distribucion de textos?. Eso tambien sirve

¿Buen balance de imagenes/animaciones/textos? Eso sirve

¿Es una pagina popular (ej: PageRank)? Muy util

¿USA URLS ESTATICAS? Si. Urls estaticas indica *indirectamente* que el contenido esta hecho para - humanos -. Las urls son intuitivas, mas cortas, son mas abstractas y menos riesgos de links muertos o invalidos. Sitios mas enfocado hacia el usuario. Urls dinamicas implica aplicaciones que pueden o no tener efectos colaterales y no ser indexables. No es malo tener URLS asi, pero el contenido en un sitio es lo #1. Sin texto indexable, el sitios es como muerto.

Mejor dicho, los buscadores, los navegadores de texto, para invidentes, etc... son ciegos sin texto: NO VEN NADA.

Importa lo de la indexacion?

Por eso dije que este tipo de temas es raro entre desarrolladores netos. No estan pensando en forma de marketing o publicidad. La forma como este hecha un sitio tiene efectos significativos en las evaluaciones, ranking y posicionamiento entre buscadores.

Siendo todo igual, un sitio que usa estandares + urls estaticas obtendra un mayor posicionamiento = mayor visitas = mas popularidad = mas ventas o mayor difusion =mayor posicionamiento = mayor visitas = mas populariodad =...

Por otro lado, existen fuertes motivaciones para los desarrolladores netos. Si no lo creen, miren el estallido de Ruby On Rails para que vean como podria ser la cosa.

Basicamente? Las Urls estaticas (no me gusta eso de limpias o sucias, confunden el proposito) mapean de lo lindo a una arquitectura MVC.

De hecho, estoy haciendo en Delphi (mejor dicho, prototipando) un CMS (administrador de contenido) que incorpore estos asuntos y muchos mas, inspirado por Ruby on Rails, Textile, TextPattern, Web 2.0 y en ultimas una recoleccion exhaustiva de lo mejor de lo mejor en estos temas...

Espero que pueda darle oxigeno a este animal... y sacarlo pronto (si no muero en el intento, les estoy avisando)

[roman]

Empezado por mamcx

Las Urls estaticas (no me gusta eso de limpias o sucias, confunden el proposito) mapean de lo lindo a una arquitectura MVC

¿Podrías profundizar en esto? No alcanzo a ver qué tiene que ver una cosa con la otra.

// Saludos

[Mick]

Parece que el tema se ha enfocado principalmente en hablar sobre la apariencia o la conveniencia del uso de un tipo de urls u otras.
Seguramente un termino medio sea lo mas correcto, realmente no conozco ningun sistema que use url limpias en todo porque en muchos casos no es lo mas adecuado, por ejemplo, navegando por cualquier web hecha en drupal veremos urls mixtas, del tipo:
http://drupal.org/forum/37?page=7

En el caso de drupal la utilizacion de las URLs limpias es mas bien un efecto secundario y no un fin en si mismo, el codigo de gestor de contenidos no sabe siquiera que existan ese tipo de urls (a excepcion de la forma de generar los link que devuelve).
Las Urls normales de drupal son asi:
http://drupal.org/index.php?q=forum/37&page=7
Tecleando esto en el navegador web se mostrara la pagina igualmente.
Realmente es una regla de reescritura del servidor web de apache (definida en el .htaccess) la que hace que funcionen, es el propio servidor web el que convierte la url limpia en una url mas sucia que es la que le llega al gestor de contenidos.

Con todo esto lo que pretendo dar a entender es que, en casos como la utilizacion de determinados engines web, se usan URLs limpias simplemente porque se puede hacer sin ningun coste adicional, no es una caracteristica especial que sea costosa de programar, basta simplemente añadir un par de lineas de configuracion al Apache (esto solo es cierto al 99%) y voila ya tenemos las URLs limpias. Y ante esta tesitura, sabiendo que no tiene ningun coste, y si comparamos las dos formas de urls:
http://drupal.org/index.php?q=forum/37&page=7
http://drupal.org/forum/37?page=7
No me cabe duda de que la segunda opcion sera la elegida por el 99.999% de los desarrolladores y usuarios que utilicen este gestor de contenidos (Quizas Emilio seal 0.0001% que no ).

Otro tema interesante que ha planteado Emilio como consecuencia de la explicacion de la forma de procesar las urls, es "el uso de un engine centralizado" vs "uso de scripts separados", esto tambien daria para una buena charla, pero es demasiado tarde hoy.

Saludos
Miguel

[dec]

Hola,

Sobre REST (Representational State Transfer) encontré un documento de Paul Reinheimer: Simple Web Services: REST (PDF) que me parece muy curioso e interesante. Por cierto que lo encontré en la Web Cluesheet - Tips for PHP Developers cuyo contenido tampoco parece estar nada mal.

[*Emilio*]

Empezado por Mick

si comparamos las dos formas de urls:
http://drupal.org/index.php?q=forum/37&page=7
http://drupal.org/forum/37?page=7
No me cabe duda de que la segunda opcion sera la elegida por el 99.999% de los desarrolladores y usuarios que utilicen este gestor de contenidos (Quizas Emilio seal 0.0001% que no ).

Me siento como el dentista que recomienda chicles con azucar

En realidad ese dentista es un tío inteligente que mira por su negocio.

Pues me temo que ni siquiera me quedo en ese supuesto 0.0001%, me gusta más la de toda la vida.

http://www.clubdelphi.com/foros/show...t=31285&page=2

Puede parecer que intento llevar la contraria, incluso a mi llega a parecérmelo con este hilo, pero es que no veo ninguna ventaja por más que me esfuerzo en ello y nadie dice algo concreto para hacerme salir del supuesto lado oscuro en que me encuentro.

[mamcx]

Date una mirada a http://www.rubyonrails.org/, en especial el videotutorial.

Porque lo de que mapea naturalmente a un desarrollo MVC (model, view, controller)?

Por esto. Imaginate la pagina de inicio. Se hacen tres cosas: Un modelo (que sacaria por ejemplo un mensaje hola mundo), un controlador (llamado INICIO) y una vista (una pagina inicio.html)

Presta atencio a la parte del CONTROLADOR. Si lo llamas "Roman" AUTOMATICAMENTE te cojeria:

www.elsitio.com/Roman

Entonces, es como autowiring: El modelo de los objetos se representa perfectamente en la aplicacion... que de hecho, es el objetivo de tener mayor disciplina en un desarrollo: Separa GUI + Logica + Contenido.

Y resulta que en los nuevos frameworks que son un stack integrado para apliaciones web MVC (que normalmente incorporan generacion de html basado en estandares, ajax, persistencia de objetos, enrutamiento de URL y mas) como RubyOnRails (ruby) TurboGears (python) y Castle (.NET) simplemente se logra una mayor productividad de desarrollo porque el flujo de trabajo es muy predecible y todo se auto-organiza.

Por otro lado, es cierto que a muchos usuarios lo de las Urls les tenga sin cuidado. Pero si miras los documentos de la w3c (reaulta que lo de las URls tambien esta estandarizado) veras que de todas maneras la gente empieza a notar (al menos algunos) que los sitios tienen una estructura.

Por ejemplo, si veo una url:

Articulos/21/Agosto/2005

me supongo que puedo darle directamente

Articulos/22/Agosto/2005

Obviamente se puede con la tipica

?Esto=1&Aquello=2


Pero a partir de cierto punto (# de parametros y su complejidad de interpretacion) ya queda dificil.

Por ultimo, fijate en el disco duro: Son Urls "limpias". A muchos no les interesa como es la estructuras de archivos pero otros si. Siendo todo igual, lo mas sencillo es mejor

Hay mas argumentos, como por ejemplo, de seguridad (es menos obvio la tecnologia y menos obvia que se puede hacer un ataque basado en urls) los de marketing y buscadores (lo mas fuerte) la abastraccion, desde el punto de vista del desarrollador, de la estructura interna.

Esto es algo que estoy trabajando el el CMS que desarrollo. Lo pienso enfocar al mercado latino. Pero resulta que a muchas empresas latinas les interesa manejar contenido en ingles. Asi que :

Version1 del sitio:

Productos/Computadores/Dell2053

Se puede tornar en

Products/Computers/Dell2053

o

Version 2:

(español colombia)
esCo/Productos/Computadores/Dell2053

a

(español mexico)

esMx/Computadores/Dell2053

Pero luego si el sitio se engrandece, se puede reorganizar:

Version 3:

/Colombia/Computadores/Dell2053
/Mexico/Computadores/Dell2053
/Usa/Products/Computers/Dell2053

Y sin embargo:

- Los urls "antiguos" se pueden dejar funcionando. En la version3 del sitio, no existe razon en hacer que


Products/Computers/Dell2053
Usa/Products/Computers/Dell2053
enUS/Products/Computers/Dell2053

Dejen de funcionar. Eso signifa que :

1- Los bookmarks que hagan los usuarios persisten durante mas tiempo

2- Los buscadores ven un sitio mas estable y terminan teniendo mas contenido que indexar, lo que aumenta la importancia

3- El sitio puede crecer de forma organica, e internamente sigue siendo:

Products.aspx?Idioma=esCo&Seccion=Computadores&Ref=Dell2053

Ahora un sub-beneficio: Auto-navegacion!

Si nos ponemos listos, nos podemos olvidar de los amarres de los archivos, directorios y subdirectorios. Y siendo algo listos, podemos autogenera todo el sistema de navegacion.

4- Se `pueden generar Urls mas simples que sea mas practicas en ambientes de navegacion mas restringido:

Los numeros de caracteres se pueden reducir o para los usuarios que son invidentes (piensen en que hay mucha gente que no puede ver o necesita asistencia en la navegacion, por ejemplo, mi tia usa un software para ello!) una navegacion:

Productos/Computadores/Dell1

a la hora de escribir en un CELULAR o una PDA o de escuchar mediante un lector de voz, es mas claro que el sistema de parametros.

Evidentemente, la ventaja de las urls estaticas aumentan en la medida que aumenta el tamaño y complejidad del sitio y disminuyen a medidad que el sitio sea mas una aplicacion web mas que uno para usuarios. Y sin enrutamiento, no tiene nigun chiste.

Por ultimo, hacer urls asi no es TAN dificil. Como mencionaron, se puede usar las propiedades de apache o un modulo http en .NET o lo que sea.

Un poco mas de info:

http://www.port80software.com/suppor...generationurls

Y no olviden que no estan obligados a hacer esto. Ni tampoco implica cambiar los sitios actuales sin razon.

[*Emilio*]

Bueno por fin, mamcx nos da algunas razones con cierto sentido común, gestión de paises, invidentes, orden en un sitio grande etc...

Ahora bien, la siguiente url http://www.clubdelphi.com/foros/arch...f-11-p-18.html

limpia, como vosotros la llamáis, incluso con terminación .html de lo cual hasta el momento no habíamos hablado, no es más que una limpia/sucia trampa cara a los buscadores, eso mismo se puede hacer con con tan sólo una línea de código, sin necesidad de modificar directivas de Apache ni .htaccess ni nada.

¿qué logramos con ello? pues tener todas la direcciones limpias como le llamáis, totalmente inútiles para el usuario ¿quién escribe una url?, por otro lado los buscadores se encuentran a sus anchas, todo perfectamente enlazado y organizado, y por si ello fuese poco, visible desde una PDA y totalmente legible por un invidente.

Además, para cada documento tendremos dos entradas en los buscadores

[dec]

Hola,

Muy interesante artículo el que has enlazado Mario. Y los que refiere el autor del mismo tampoco parecen tener desperdicio:

Articles
Numerous articles have been written about the need for clean URLs. A few of the more prominent ones are cited here.

• Tim Berners Lee's Cool URIs don't change
• Jakob Nielsen on URL as UI
• Bill Humphries @ Zeldman's on URLs! URLs! URLs!
• Clean Up Those URLs with Apache
• Making "clean" URLs with Apache and PHP
• Search Engine Friendly URLs with PHP and Apache: Part I and Part II