Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Web Development
Code

HTTP Conciso: Recursos HTTP

by
Difficulty:IntermediateLength:LongLanguages:
This post is part of a series called HTTP Succinctly.
HTTP Succinctly: HTTP Messages

Spanish (Español) translation by Jonathan Samines (you can also view the original English article)

HTTP es el protocolo que nos permite comprar hornos de microondas de Amazon.com, reunirnos con un viejo amigo en un chat de Facebook y ver videos de gatos graciosos en YouTube. HTTP es el protocolo detrás de la World Wide Web (Red Global Ampliada). Éste permite a un servidor web de un centro de datos en los Estados Unidos enviar información a un Café Internet en Australia, donde un joven estudiante puede leer una página web describiendo la Dinastía Ming en China.

En éste libro le echaremos un vistazo a HTTP desde la perspectiva de un desarrollador de software. Tener un sólido entendimiento de HTTP puede ayudarte a escribir mejores aplicaciones y servicios web. También puede ayudarte a depurar aplicaciones y servicios cuando las cosas van mal. Estaremos cubriendo todo lo básico incluyendo recursos, mensajes, conexiones y seguridad, y como se relacionan con HTTP.

Empezaremos examinando los recursos.

Recursos

Quizás la parte más conocida de la web es la dirección HTTP. Cuando quiero encontrar una receta para un plato de brócoli, lo cual casi nunca ocurre, entonces abro mi explorador web e ingreso http://food.com en la barra de direcciones para ir al sitio web de food.com y busco las recetas. Mi explorador web entiende ésta sintaxis y sabe que necesita realizar una petición HTTP a un servidor llamado food.com. Hablaremos más tarde acerca de lo que "hacer una petición HTTP" quiere decir y todos los detalles de red involucrados. Por ahora, queremos enfocarnos en la dirección: http://food.com.


Localizadores de Recursos.

La dirección http://food.com es lo que nosotros llamamos una URL- un localizador uniforme de recursos. Esta representa un recurso específico en la web. En éste caso, el recurso es la página principal del sitio web food.com. Los recursos son cosas con las que quiero interactuar en la web. Imágenes, páginas, archivos y videos, todos son recursos.

Existen billones, sino trillones de lugares a los cuales ir en Internet- en otras palabras, existen trillones de recursos. Cada recuso tendrá una URL que puedo utilizar para encontrarlo. http://news.google.com es un lugar diferente a http://news.yahoo.com. Estos son dos nombres diferentes, dos compañías diferentes, dos sitios web diferentes y por lo tanto, dos URLs diferentes. Claro, existirán también diferentes URLs dentro de un mismo sitio web. http://food.com/recipe/broccoli-salad-10733/ es la dirección URL de una página con una receta de ensalada de brócoli, mientras que http://food.com/recipe/grilled-cauliflower-19710/ está aún en food.com, pero es un recurso diferente describiendo una receta de coliflor.

Podemos dividir la última URL en tres partes:

  1. http, la parte antes de ://, es lo que nosotros llamamos esquema URL. El esquema describe como acceder a un recurso particular, y en éste caso le indica al explorador que utilice el protocolo de transferencia de hipertexto. Más adelante, también veremos un esquema diferente, HTTPS, el cual es el protocolo HTTP seguro. Podrías toparte con otros esquemas, como el protocolo de transferencia de archivos FTP y mailto para direcciones de correo electrónico.

    Todo después de :// será específico a un esquema en particular. Así, una URL HTTP legal podría no ser legal para una URL mailto- estas dos no son en realidad intercambiables (lo cual tiene sentido, porque describen distintos tipos de recursos).

  2. food.com es el host. Éste nombre de host, le indica al explorador el nombre del equipo que hospeda el recurso. El equipo usará el Sistema de Nombres de Dominio (DNS) para traducir food.com a una dirección de red, y entonces sabrá exactamente a dónde enviar la solicitud para el recurso. También puedes especificar la parte del host de la URL utilizando una dirección IP.
  3. /recipe/grilled-cauliflower-19710/ es la ruta de la URL. El host food.com debería reconocer el recurso específico que está siendo solicitado por ésta ruta y responder apropiadamente.

Algunas veces una URL apuntará a un archivo en el sistema de archivos del host o en el disco duro. Por ejemplo, la URL http://food.com/logo.jpg podría apuntar a una imagen que en realidad existe en el servidor food.com. Sin embargo, los recursos también pueden ser dinámicos. La URL http://food.com/recipes/brocolli probablemente no haga referencia a un archivo real en el servidor food.com. En su lugar, algún tipo de aplicación ejecutándose en el host food.com tomará la solicitud y construirá un recurso usando el contenido de una base de datos. La aplicación puede estar construida usando ASP.NET, PHP, Perl, Ruby on Rails, o alguna otra tecnología web que sepa como responder a las solicitudes entrantes, creando HTML para que un explorador lo muestre.

De hecho, en éstos días muchos sitios web intentan evitar tener cualquier tipo de nombre de archivo real en sus URLs. Para los principiantes, los nombres de archivo normalmente son asociados a un tecnología específica, como .aspx para las tecnologías Microsoft ASP.NET. Muchas URLs no tendrán en cuenta la tecnología usada para hospedarla y servirla. En segundo lugar, muchos sitios web quieren colocar palabras clave en una URL (como tener /recipe/broccoli/ en la URL para una receta de brócoli). Tener éstas palabras claves en la URL es una forma de optimización de motores de búsqueda (SEO) que clasificará el recurso más arriba en los resultados del motor de búsqueda. Las palabras clave descriptivas y no los nombres de archivos, son importantes para las URLs en éstos días.

Algunos recursos también llevarán al explorador a descargar recursos adicionales. La página principal de food.com incluirá imágenes, archivos Javascript, CSS y otros recursos que serán combinados para presentar la "página principal" de food.com.

Figure 1 foodcom home page

Página principal de food.com.

Puertos, Query Strings y Fragmentos.

Ahora que sabemos sobre los esquemas URL, host y rutas, también echémosle un vistazo a una URL con un número de puerto:

El número 80 representa el número de puerto que el host está utilizando para escuchar las solicitudes HTTP. El número de puerto por defecto para HTTP es el puerto 80, por lo que generalmente ves éste número de puerto omitido en una URL. Solo necesitas especificar un número de puerto si el servidor está escuchando en otro puerto que no sea el 80, lo cual normalmente sólo ocurre en entornos de pruebas, depuración o desarrollo. Echémosle un vistazo a otra URL.

Todo lo que sigue tras ? (el signo de interrogación) es conocido como query. El query, también llamado query string, contiene información para el uso o interpretación del sitio web de destino. No existe un estándar formal para la forma como el query string debería lucir, por lo que es técnicamente un problema de la aplicación la interpretación de los valores que encuentre, sin embargo, verás la mayor parte de los query strings usados para pasar pares de nombre-valor en la forma name1=value1&name2=value2.

Por ejemplo:

Existen dos pares de nombre-valor en éste ejemplo. El primer par tiene el nombre "first" y el valor "Scott". El segundo par tiene el nombre "last" con el valor "Allen". En nuestra anterior URL (http://www.bing.com/search?q=broccoli), el motor de búsqueda Bing verá el nombre "q" asociado al valor "broccoli". Resulta que el motor de búsqueda Bing busca un valor de "q" para usarlo como término de búsqueda. Podemos pensar en la URL como la URL del recurso que representa los resultados de búsqueda de Bing para brócoli.

Finalmente, una URL más:

La parte tras el símbolo # es conocida como fragmento. El fragmento es diferente que las otras partes que hemos visto recientemente, porque a diferencia de la ruta URL o el query string, el fragmento no es procesado por el servidor. El fragmento es solo utilizado en el cliente e identifica una sección particular de un recurso. Específicamente, el fragmento es típicamente utilizado para identificar un elemento HTML específico en una página por el ID del elemento.

Los exploradores web típicamente alinearán la visualización inicial de una página web de modo que el "top" del elemento identificado por el fragmento esté en el "top" de la pantalla. Como un ejemplo, la URL http://odetocode.com/Blogs/scott/archive/2011/11/29/programming-windows-8-the-sublime-to-the-strange.aspx#feedback tiene el valor de fragmento "feedback". Si sigues la dirección URL, tu explorador web debería desplazarse hacía abajo para mostrarte la sección de feedback en un post particular de mi blog. Tu explorador obtuvo el recurso entero (el post del blog), pero enfocó tu atención a un área específica- la sección de feedback. Puedes imaginar que el HTML para un post luce de la siguiente forma (con todo el texto de contenido omitido):

El cliente se asegura que el elemento con el ID "feeback" esté en la parte superior de la página.

Si juntamos todo lo que hemos aprendido hasta ahora, sabemos que una URL está dividida en las siguientes partes:


Codificación de URL

Todos los desarrolladores de software que trabajan con la web debería estar conscientes sobre los problemas de codificación con las URLs. Según la documentación oficial, las URLs de gran tamaño se representan para hacerlas tan usables e interoperables como sea posible. Una URL debería ser tan fácil de comunicar a través de correo electrónico como de forma impresa o en una estampilla pegada a un Ford Windstar 2001. Por ésta razón, los estándares de internet definen caracteres inseguros para las URLs. Por ejemplo, el caracter de espacio es considerado inseguro porque los caracteres de espacio pueden aparecer o desaparecer erróneamente cuando una URL está en forma impresa (¿es éste uno o dos espacios en tu tarjeta de presentación?)

Otros caracteres inseguros incluyen el símbolo numeral (#) porque es usado para delimitar un fragmento, y el símbolo de intercalación (^) porque no es siempre transmitido correctamente a través de los dispositivos de red. De hecho, el RFC 3986 (la "ley" para las URLs), define que los caracteres seguros para las URLs son caracteres alfanuméricos en codificación US-ASCII, así como otros símbolos especiales adicionales como los dos puntos (:) y la diagonal (/).

Afortunadamente, aún puedes transmitir caracteres inseguros en una URL, pero todos los caracteres inseguros deben estar porcentualmente-codificados (también conocido como codificación URL). %20 es la codificación para el caracter de espacio (donde 20 es el valor hexadecimal para el caracter de espacio codificado en US-ASCII).

Como un ejemplo, digamos que quieres crear la URL para un archivo llamado "^my resume.txt". en someserver.com. La URL codificada legalmente luciría así:

Ambos el caracter de ^ y el espacio han sido porcentualmente-codificados. La mayoría de los frameworks de aplicaciones web proporcionarán un API para una fácil codificación de URL. En el servidor, deberías pasar tus URLs creadas dinámicamente a través de un API de codificación solo en caso de que uno de los caracteres inseguros aparezcan en la URL.


Recursos y Tipos Media

Hasta ahora nos hemos enfocado en las URLs y hemos simplificado todo lo demás. Pero, ¿qué quiere decir cuándo ingresamos una URL en el explorador? Típicamente quiere decir que queremos obtener o visualizar algún recurso. Existe una tremenda cantidad de material para visualizar en la web, y posteriormente veremos también como HTTP también nos permite crear, eliminar y actualizar recursos. Por ahora, nos enfocaremos en la obtención.

No hemos sido muy específicos sobre los tipos de recursos que queremos obtener. Hay miles de tipos diferentes recursos en la web- imágenes, documentos de hipertexto, documentos XML, video, audio, aplicaciones ejecutables, documentos de Microsoft Word y muchos más.

Para que un host pueda servir un recurso apropiadamente, y para que un cliente muestre un recurso apropiadamente, las partes involucradas tienen que ser específicos y precisos sobre el tipo de recurso. ¿Es el recurso una imagen? ¿Es el recurso una película? No quisiéramos que nuestros exploradores web intentaran renderizar una imagen PNG como texto, y no quisiéramos que intentaran interpretar el hipertexto como una imagen.

Cuando un host responde a una solicitud HTTP, devuelve un recurso y también especifica el tipo de contenido (también conocido como media type) del recurso. Veremos los detalles de como el tipo de contenido (content type) aparece en un mensaje HTTP en el siguiente capítulo.

Para especificar los tipos de contenido, HTTP depende de los estándares de Extensiones Multipropósito de Correo por Internet (MIME). Aunque MIME fue originalmente diseñado para las comunicaciones por correo, HTTP utiliza los estándares MIME para el mismo propósito, el cual es etiquetar el contenido en tal forma que un cliente conocerá el contenido.

Por ejemplo, cuando un cliente solicita una página web HTML, el host puede responder la solicitud HTTP con algún HTML que etiqueta como "text/html". La parte "text" es el tipo media principal, y "html" es el subtipo media. Cuando responde a una solicitud para una imagen, el host etiquetará el recurso con el tipo de contenido "image/jpeg" para archivos JPG, "image/gif" para archivos GIF o"image/png" para archivos PNG. Estos tipos de contenido son tipos MIME estándar y son literalmente lo que aparecerá en la respuesta HTTP.


Una breve nota sobre las extensiones de archivo

Podrías pensar que un explorador se puede fiar de la extensión del archivo para determinar el tipo de contenido de la solicitud entrante. Por ejemplo, si mi explorador solicita "frog.jpg" debería tratar el recurso como un archivo JPG, pero tratar a "frog.gif" como un archivo GIF. Sin embargo, para la mayoría de los exploradores, la extensión del archivo es el último lugar al que irán para determinar el tipo de contenido real

Las extensiones de archivo pueden ser incorrectas, y solo porque hemos solicitado un archivo JPG no quiere decir que el servidor tenga que responder con la información codificada en formato JPG. Microsoft documenta que Internet Explorer (IE) busca primero la etiqueta de tipo de contenido especificada por el host. Si el host no proporciona un tipo de contenido, IE escaneará los primeros 200 bytes de la respuesta intentando descifrar el tipo de contenido. Finalmente, si IE no encuentra el tipo de contenido y no puede descifrarlo, se apoyará en la extensión del archivo usada en la solicitud del recurso. Esta es una razón del por qué la etiqueta de tipo de contenido es importante, pero está lejos de ser la única razón.


Negociación de Tipo de Contenido

Aunque tendemos a pensar en HTTP como algo usado para servir páginas web, de hecho la especificación HTTP describe un protocolo flexible y genérico para mover información en alta fidelidad. Parte del trabajo de mover información es asegurarse de que todas las partes involucradas saben como interpretar la información, y esto es el porque de la importancia de las configuraciones de tipos media (media-type).

Sin embargo, los tipos media no son solo para los hosts. Los clientes juegan un rol sobre el tipo media que un host devuelve tomando parte en la negociación del tipo de contenido.

Un recurso identificado por una única URL puede tener múltiples representaciones. Toma por ejemplo, la receta de brócoli que mencionamos anteriomente. Ésta única receta podría tener representaciones en diferentes idiomas (Inglés, Francés y Alemán). La receta aún así podría tener representaciones en diferentes formatos (HTML, PDF y texto plano). Todos son el mismo recurso y la misma receta, pero en diferentes representaciones.

La pregunta obvia es : ¿Qué representaciones debería seleccionar el servidor? La respuesta está en el mecanismo de negociación de contenidos descrito por la especificación HTTP. Cuando un cliente hace una solicitud HTTP a una URL, el cliente puede especificar los tipos media que aceptará. Los tipos media no son solo para que el host etiquete los recursos salientes, sino también para que los clientes especifiquen los tipos media que quieren consumir.

El cliente especifica que aceptará en el mensaje de solicitud saliente. Nuevamente, veremos los detalles de éste mensaje en la siguiente sesión, pero imagina una solicitud a http://food.com diciendo que aceptará una representación en idioma Alemán. Queda en el servidor tratar de cumplir con la solicitud. El host podría enviar un recurso textual que aún esté en inglés, lo cual probablemente decepcione a un usuario de habla alemán, pero esto es el por qué lo llamamos negociación de contenidos y no contenido definitivo.

Los exploradores web son piezas sofisticadas de software que pueden lidiar con diferentes tipos de representaciones de recursos. La negociación de contenido es algo que lo que un usuario probablemente nunca tenga que preocuparse, pero para los desarrolladores de software (especialmente los desarrolladores de servicios web) la negociación de contenido es parte de lo que hace excelente a HTTP. Una fragmento de código escrito en Javascript puede hacer una solicitud a un servidor y solicitar una representación JSON. Un fragmento de código escrito en C++ puede realizar una solicitud a un servidor y solicitar una representación XML. En ambos casos, si el host puede satisfacer la solicitud, la información llegará al cliente en el formato ideal para su parseo y consumo.


¿Dónde estamos?

En éste punto hemos ido tan lejos como pudimos sin adentrarnos en los detalles esenciales de como luce un mensaje HTTP. Hemos aprendido sobre URLs, codificación de URL y tipos de contenido. Es hora de ver cómo estas especificaciones de tipo de contenido lucen al viajar a través de los cables.

¡Sé el primero en conocer las nuevas traducciones–sigue @tutsplus_es en Twitter!

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.