¿Por qué algunas URL de sitios no incluyen una extensión de archivo?

Question

Estaba navegando por Internet y noté, YouTube, por ejemplo, contiene una URL como esta para indicar una página de video: http://www.youtube.com/watch?v=gwS1tGLB0vc.

Mi sitio utiliza una URL como esta para una página de tema: http://www.example.com/page.php?topic_id=6f3246d0sdf42c2jb67abba60ce33d5cc.

La diferencia es que si aún no lo ha notado en youtube, no hay una extensión de archivo para su página de visualización, entonces me pregunto, ¿por qué algunos sitios no usan extensiones de archivo y para qué sirve?

Answer 1

Las extensiones de archivo no se utilizan debido a la idea de que los URI (y por lo tanto Las URL) deben ser independientes de la implementación: si desea acceder a las direcciones de George W. Bush, debe poder ir al http://www.whitehouse.gov/presidents/georgewbush/addresses (por ejemplo). Si los servidores de la Casa Blanca usan PHP, Python o Perl no le importan al usuario final, por lo que no deberían verlo. Al usuario final no le importa cómo se generó la página, porque todos los idiomas web producen el mismo HTML, CSS y similares, y solo están viendo la página en su navegador web.

La mayoría de los frameworks web crean esta funcionalidad de forma predeterminada, precisamente por este motivo, y se puede realizar independientemente de la reescritura de URL en la mayoría de los servidores web. Este ideal está codificado en la Guía de estilo W3C, que sin duda es un gran defensor de esta idea tan ampliamente aceptada. Se describe en su guía, "Cool URIs Don't Change", que debería aclarar las cosas si aún no entiendes el razonamiento aquí. Ese documento es la declaración de referencia sobre el tema y el estándar de facto para los marcos.

Vale la pena señalar que por lo general los archivos que terminan siendo descargado (ya veces los archivos de datos utilizados en AJAX) todavía tienen sus extensiones de archivo intacta - http://example.com/song.mp3 o http://example.com/whitepaper.pdf - debido a que están destinados a ser guardado en final- computadora del usuario, donde las extensiones de archivos son importantes. Las extensiones no se incluyen para las páginas que son simplemente visualizadas - que es la mayoría de las páginas.

Answer 2

La clave es el campo Content-Type del encabezado de respuesta HTTP. Algo así:

HTTP 200 OK 
Content-Type: video/flv 
Content-Length: 102345 

DATA-DATA-DATA-DATA-DATA-DATA-.... 

Consulte también:

Content-Disposition: attachment; filename=genome.jpeg; 
    modification-date="Wed, 12 Feb 1997 16:29:51 -0500"; 

Más detalles: http://en.wikipedia.org/wiki/MIME

Answer 3

tener o no tener la extensión es irrelevante. El navegador actúa sobre el tipo MIME devuelto por el servidor, no cualquier extensión utilizada en la URL.

Answer 4

Lo que está viendo es un ejemplo de enrutamiento de URL. En lugar de apuntar a un archivo específico (por ejemplo, page.php), el servidor está utilizando una tabla de enrutamiento o configuración que dirige la solicitud a un controlador que realmente representa el html (o cualquier otra cosa según el tipo de mime devuelto). Si nota, StackOverflow utiliza el mismo mecanismo.

Answer 5

Hay muchas respuestas posibles para esto. Así es como se configuran los servidores de aplicaciones web que resultan en lo que está interpretando su navegador web. Puede haber situaciones en las que esté utilizando reescritura de URL o enrutamiento, y como otros han dicho, qué manejadores está proporcionando para las URL o extensiones solicitadas.

Podría tener una URL como "http://cory.com/this/really/doesnt/exist" y que de hecho esté apuntando a "http://cory.com/this.does.exist.123" si quisiera.

Answer 6

Bueno, las extensiones de archivos no sirven para nada en Internet. Al navegador no le importa la extensión del archivo. Puede servir un archivo CSS como .avi. Entonces, ¿por qué no simplemente dejarlo afuera? Esto permite URLs más cortas.

Además, "reescribir" una url permite urls más legibles. Puede que no entienda /categories.php?id=455 pero lo hace /455-some-category.

Si quiere hacer esto usted mismo y está usando Apache eche un vistazo a mod_rewrite.

Answer 7

Cuando preguntas '¿Por qué?' ¿Estás preguntando por una razón técnica o una razón de diseño? Algunas personas ya respondieron la técnica, así que solo comentaré sobre el diseño.

Básicamente se reduce a que la url es un punto final. Es un lugar al que los usuarios/servicios deben llegar. La extensión es irrelevante en la mayoría de los casos. Si un usuario está navegando en la web y va al http://site.com/users, está esperando una lista de usuarios. No le importa que no diga .html o .php. Y como diseñador que usa esas extensiones realmente no tiene sentido. Desea que su aplicación tenga sentido, y esas extensiones realmente no brindan ninguna información que el usuario necesite.

Los tiempos en los que desearía utilizarlos eran si estuviese creando un servicio que otras aplicaciones utilizarían. Luego, puede optar por usar una extensión para indicar qué tipo de datos uno esperaría recuperar (.json, .xml, etc.). Hay personas trabajando en las pautas de diseño y las especificaciones para esto, pero todo es temprano

Básicamente, esas extensiones se utilizan porque así es como funcionaban los servidores web/clientes de manera predeterminada. A medida que el desarrollo web ha madurado, comenzamos a tratar las urls de forma más profesional e intentamos que tengan sentido para las personas que las leen o las utilizan.

Answer 8

El comportamiento normal de un servidor web es asignar la ruta URI solicitada a un archivo en algún lugar del directorio raíz del documento. Entonces http://example.com/foo/bar simplemente se mapea en /path/do/document/root/foo/bar. Además, el servidor web necesita saber cómo manejar un archivo. Esto se hace a menudo con la extensión de nombre de archivo. Por lo tanto, los archivos con la extensión de nombre de archivo .php son manejados por el intérprete de PHP.

Ahora, aparte de este comportamiento normal, la mayoría de los servidores web tienen características que permiten cambiar tanto la asignación (es decir, URL rewriting) como la manera en que se maneja un archivo sin una extensión de nombre de archivo.

En caso de que el servidor web Apache, el primero puede hacerse con mod_rewrite:

RewriteEngine on 
RewriteRule ^/watch$ /watch.php 

Y el último se puede hacer con mod_mime:

<File watch> 
    ForceType application/x-httpd-php 
</File> 

(Ok, en realidad esto no es característica mod_mime pero una característica core.)

Answer 9

Si bien las extensiones no son importantes para el navegador, que solo usa los encabezados que se transfieren a él para determinar qué mostrar y cómo mostrarlo, es probable que haga asunto en el servidor. Por ejemplo, su caja podría tener instalado un intérprete de php y un intérprete de ruby, pero su servidor web tiene archivos de configuración para mapear extensiones de archivos a tipos MIME. Por ejemplo, desde php5.conf de Apache:

AddType application/x-httpd-php .php .phtml .php3 

que le dice a Apache que los archivos con la extensión .php, .phtml y .php3 deben ser reconocidos como archivos PHP.

Sin embargo, dado que las extensiones no significan nada para el cliente, las URL a menudo se ven "más bonitas" sin ellas. Para hacerlo, se pueden usar tecnologías como Apache's mod_rewrite para "reescribir" URL de cliente-tierra para que tengan sentido en el servidor.

Por ejemplo, podría configurar mod_rewrite reglas para reescribir una URL como http://yourblog.com/article/the-article-you-wrote (que se ve mejor y es más fácil de escribir y de recordar) a http://yourblog.com/articles.php?title=the-article-you-wrote, que Apache puede utilizar para encaminar adecuadamente la solicitud a su script PHP.

Answer 10

La url, se debe considerar correctamente como parte de la interfaz de usuario. Como tal, debe diseñarse para transmitir información sobre dónde se encuentra el usuario en el sitio y la estructura del sitio.

un enlace como:

mysite.com/sport/soccer/brazil_wins_worldcup

le dice al usuario mucho sobre la estructura del sitio, y en la que actualmente es. Por el contrario:

mysite.com/article.php?cateogry=12 & articleid = 371

es inútil, sino que expone irrelevantes implementation-detalles como el idioma que se utiliza para hacer el sitio, y lo que el id de ese artículo (probablemente almacenado en una base de datos con ese ID)

Además de este argumento estetico (no exponga al usuario a detalles de implementación irrelevantes) también ayuda a que el sitio sea a prueba del futuro. Porque si nunca expusiste tu idioma de elección, puedes actualizar a Ruby o Python, sin ningún otro enlace en el mundo que te señale, ahora es un 404.

Diseña urls para que tengan sentido para los usuarios, y para ser a prueba de futuro.

Answer 11

"www.youtube.com/watch" es un directorio de YouTube. Por lo tanto, básicamente se puede escribir como "www.youtube.com/watch/" con la barra inclinada final.

Answer 12

Regla: (.) ​​Las extensiones de archivo no deben ser incluidos en los URI

En la Web, el período de caracteres se utiliza comúnmente para separar el nombre de archivo y partes de extensión de un URI. Una API REST no debe incluir extensiones de archivos artificiales en URI para indicar el formato del cuerpo de la entidad de un mensaje. En su lugar, deben confiar en el tipo de medio, como se comunica a través del encabezado Content-Type, para determinar cómo procesar el contenido del cuerpo.

(1) http://api.college.restapi.org/students/3248234/transcripts/2005/fall.json (2) http://api.college.restapi.org/students/3248234/transcripts/2005/fall

(1) Las extensiones de archivo no deben ser utilizados para indicar el formato preferencia. (2) Se recomienda a los clientes de la API REST que utilicen el mecanismo de selección de formato proporcionado por HTTP , el encabezado de solicitud de aceptación. referencias: diseño REST api libro de reglas

Answer 13

debajo de lo que uso en mi .htaccess para hacer que la url aún se ejecute correctamente sin la extensión HTML o PHP.

RewriteEngine on 
RewriteCond %{REQUEST_FILENAME} !-d 
RewriteCond %{REQUEST_FILENAME}\.html -f 

significa que si el archivo con el nombre especificado en el navegador no se emparejan con el directorio (-d) o archivos (f) en su servidor web, a continuación, volver a escribir la regla de abajo

RewriteRule ^(.*)$ $1.html 

no estoy seguro de cómo el trabajo a continuación, pero creo que después de que se vuelva a escribir con hTML y si todavía no se vuelva a grabar a juego con php

RewriteCond %{REQUEST_FILENAME}\.php -f 
RewriteRule ^(.*)$ $1.php 

si todavía no se ajuste que se muestra la página 404.

También puede redirigir 404 con el código de abajo en .htaccess

ErrorDocument 404 /404.html 

importancia es el código está trabajando en mi sitio.

http://mintnet.net/services

http://php.mintnet.net/home

aquellos no necesita la extensión de archivo.