---
title: Visión General Cliente-Servidor
slug: Learn/Server-side/First_steps/Client-Server_overview
tags:
  - Aprendizaje
  - Codificación de scripts
  - Guía
  - Principiante
  - Programación lado servidor
  - Servidor
  - introducción
translation_of: Learn/Server-side/First_steps/Client-Server_overview
original_slug: Learn/Server-side/Primeros_pasos/Vision_General_Cliente_Servidor
---
<div>{{LearnSidebar}}</div>

<div>{{PreviousMenuNext("Learn/Server-side/First_steps/Introduction", "Learn/Server-side/First_steps/Web_frameworks", "Learn/Server-side/First_steps")}}</div>

<p class="summary">Ahora que conoces el propósito y los beneficios potenciales de la programación de lado-servidor vamos a examinar en detalle lo que ocurre cuando un servidor recibe una "petición dinámica" desde un explorador web. Ya que el código de lado servidor de la mayoría de los sitios web gestiona peticiones y respuestas de formas similares, este artículo te ayudará a entender lo que necesitas hacer para escribir la mayor parte de tu propio código.</p>

<table class="learn-box standard-table">
 <tbody>
  <tr>
   <th scope="row">Prerequisitos:</th>
   <td>Conocimientos básicos de computación. Noción básica de lo que es un servidor.</td>
  </tr>
  <tr>
   <th scope="row">Objetivo:</th>
   <td>Comprender lo que son las interacciones cliente-servidor en un sitio web dinámico, y en particular que operaciones necesita realizar el código de lado servidor.</td>
  </tr>
 </tbody>
</table>

<p>No hay código real en el debate porque ¡todavía no hemos seleccionado el framework web que usaremos para escribir nuestro código! Sin embargo este debate sí que es muy relevante incluso ahora, porque el comportamiento descrito debería ser implementado por tu código de lado servidor independientemente de qué lenguaje de programación o framework web hayas seleccionado.</p>

<h2 id="Servidores_Web_y_HTTP_(iniciación)">Servidores Web y HTTP (iniciación)</h2>

<p>Los exploradores web se comunican con los <a href="https://developer.mozilla.org/en-US/docs/Learn/Common_questions/What_is_a_web_server">servidores web</a> usando el Protocolo de Transferencia de HyperTexto (<strong>H</strong>yper<strong>T</strong>ext<strong>T</strong>ransfer <strong>P</strong>rotocol <a href="/en-US/docs/Web/HTTP">HTTP</a>). Cuando pinchas en un enlace sobre una página web, envías un formulario o ejecutas una búsqueda, el explorador envía una petición (<em>Request) </em>HTTP al servidor.</p>

<p>Esta petición incluye:</p>

<ul>
 <li>Una URL que identifica el servidor de destino y un recurso (ej. un fichero HTML, un punto de datos particular en el servidor, o una herramienta a ejecutar).</li>
 <li>Un método que define la acción requerida (por ejemplo, obtener un fichero o salvar o actualizar algunos datos). Los diferentes métodos/verbos y sus acciones asociadas se listan debajo:
  <ul>
   <li><code>GET</code>: Obtener un recurso específico (ej. un fichero HTML que contiene información acerca de un producto  o una lista de productos).</li>
   <li><code>POST</code>: Crear un nuevo recurso (ej. añadir un nuevo artículo a una wiki, añadir un nuevo contacto a una base de datos). </li>
   <li><code>HEAD</code>: Obtener la información de los metadatos sobre un recurso específico sin obtener el cuerpo entero tal como haría <code>GET</code>. Podrías, por ejemplo, usar una petición <code>HEAD</code> para encontrar la última vez que un  recurso fue actualizado, y a continuación usar la petición <code>GET</code> (más "cara") para descargar el recurso sólo si éste ha cambiado. </li>
   <li><code>PUT</code>: Actualizar un recurso existente (o crear uno nuevo si no existe).</li>
   <li><code>DELETE</code>: Borrar el recurso específico.</li>
   <li><code>TRACE</code>, <code>OPTIONS</code>, <code>CONNECT</code>, <code>PATCH</code>: Estos verbos son para tareas menos comunes/avanzadas, por lo que no los trataremos aquí.</li>
  </ul>
 </li>
 <li>Se puede codificar información adicional con la petición (por ejemplo, datos de un formulario HTML). La información puede ser codificada como:
  <ul>
   <li>Parámetros URL: Las peticiones <code>GET</code> codifican los datos en la URL enviada al servidor añadiendo al final pares nombre/valor — por ejemplo, <code>http://mysite.com<strong>?name=Fred&amp;age=11</strong></code>. Siempre encontrarás un signo de interrogación(<code>?</code>) separando los parámetros URL del resto de la misma, un signo igual (<code>=</code>) separando cada nombre de su valor asociado y un ampersand (<code>&amp;</code>) separando cada par. Los parámetros URL son inherentemente "inseguros" ya que pueden ser modificados por los usuarios y ser enviados de nuevo. Como consecuencia los parámetros URL/peticiones <code>GET</code> no se usan para peticiones de actualización de datos en el servidor.</li>
   <li>Datos <code>POST</code>. Las peticiones <code>POST</code> añaden nuevos recursos, cuyos datos están codificados dentro del cuerpo de la petición.</li>
   <li>Cookies de lado cliente. Los Cookies contienen datos de sesión acerca del cliente, incluyendo las claves que el servidor puede usar para determinar su estado de incio de sesión y los permisos/accesos a los recursos.</li>
  </ul>
 </li>
</ul>

<p>Los servidores web esperan los mensajes de petición de los clientes, los procesan cuando llegan y responden al explorador web con un mensaje de respuesta HTTP. La respuesta contiene un <a href="/en-US/docs/Web/HTTP/Status">código de estado de respuesta HTTP</a> que indica si la petición ha tenido éxito o no (ej. "<code>200 OK</code>" para indicar éxito, "<code>404 Not Found</code>" si el resurso no ha podido ser encontrado,  "<code>403 Forbidden</code>" si el usuario no está autorizado a acceder al recurso, etc). El cuerpo de la respuesta de éxito a una petición <code>GET</code> contendría el recurso solicitado.</p>

<p>Cuando se devuelve una página HTML es renderizada por el explorador web. Como parte del procesamiento el explorador puede descubrir enlaces a otros recursos (ej. una página HTML normalmente referencia las páginas JavaScript y CSS), y enviará peticiones HTTP separadas para descargar estos ficheros.</p>

<p>Los sitios web tanto estáticos como dinámicos (abordados en las secciones siguientes) usan exactamente los mismos protocolos/patrones de comunicación.</p>

<h3 id="Ejemplo_de_peticiónrespuesta_GET">Ejemplo de petición/respuesta GET</h3>

<p>Puedes realizar una petición <code>GET</code> simplemente pinchando sobre un enlace o buscando en un sitio (como la página inicial de un motor de búsquedas). Por ejemplo, la petición HTTP que se envía cuando realizas una búsqueda en MDN del término "visión general cliente servidor" se parecerá mucho al texto que se muestra más abajo (no será idéntica porque algunas partes del mensaje dependen de tu explorador/configuración).</p>

<div class="note">
<p>El formato de los mensajes HTTP está definido en el "estándard web" (<a href="http://www.rfc-editor.org/rfc/rfc7230.txt">RFC7230</a>). No necesitas conocer este nivel de detalle, pero al menos ¡ahora sabes de donde viene todo esto!</p>
</div>

<h4 id="La_petición">La petición</h4>

<p>Cada linea de la petición contiene información sobre ella. La primera parte se llama <strong>cabecera</strong> o <strong>header</strong>, y contiene información útil sobre la petición, de la misma manera que un <a href="/en-US/docs/Learn/HTML/Introduction_to_HTML/The_head_metadata_in_HTML">HTML head</a> contiene información útil sobre un documento (pero no el contenido mismo, que está en el cuerpo):</p>

<pre>GET https://developer.mozilla.org/en-US/search?q=client+server+overview&amp;topic=apps&amp;topic=html&amp;topic=css&amp;topic=js&amp;topic=api&amp;topic=webdev HTTP/1.1
Host: developer.mozilla.org
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Referer: https://developer.mozilla.org/en-US/
Accept-Encoding: gzip, deflate, sdch, br
<code>Accept-Charset: ISO-8859-1,UTF-8;q=0.7,*;q=0.7</code>
Accept-Language: en-US,en;q=0.8,es;q=0.6
Cookie: sessionid=6ynxs23n521lu21b1t136rhbv7ezngie; csrftoken=zIPUJsAZv6pcgCBJSCj1zU6pQZbfMUAT; dwf_section_edit=False; dwf_sg_task_completion=False; _gat=1; _ga=GA1.2.1688886003.1471911953; ffo=true
</pre>

<p>La primera y segunda líneas contienen la mayoría de la información de la que hemos hablado arriba:</p>

<ul>
 <li>El tipo de petición (<code>GET</code>).</li>
 <li>La URL del recurso de destino (<code>/en-US/search</code>).</li>
 <li>Los parámetros URL (<code>q=client%2Bserver%2Boverview&amp;topic=apps&amp;topic=html&amp;topic=css&amp;topic=js&amp;topic=api&amp;topic=webdev</code>).</li>
 <li>El destino/host del sitio web (developer.mozilla.org).</li>
 <li>El final de la primera linea también incluye una cadena corta que identifica la versión del protocolo utilizado (<code>HTTP/1.1</code>).</li>
</ul>

<p>La última linea contiene información sobre los cookies del lado cliente — puedes ver que en este caso el cookie incluye un id para gestionar las sesiones (<code>Cookie: sessionid=6ynxs23n521lu21b1t136rhbv7ezngie; ...</code>).</p>

<p>Las líneas restantes contienen información sobre el explorador web usado y la clase de respuestas que puede manejar. Por ejemplo, puedes ver aquí que:</p>

<ul>
 <li>Mi explorador (<code>User-Agent</code>) es Mozilla Firefox (<code>Mozilla/5.0</code>).</li>
 <li>Puede aceptar información comprimida gzip (<code>Accept-Encoding: gzip</code>).</li>
 <li>Puede aceptar el conjunto de caracteres especificado (<code>Accept-Charset: ISO-8859-1,UTF-8;q=0.7,*;q=0.7</code>) y los idiomas (<code>Accept-Language: de,en;q=0.7,en-us;q=0.3</code>).</li>
 <li>La linea <code>Referer</code> indica la dirección de la página web que contenía el enlace a este recurso (es decir, el origen de la petición, <code>https://developer.mozilla.org/en-US/</code>).</li>
</ul>

<p>Las peticiones HTTP también pueden tener un cuerpo, pero está vacío en este caso.</p>

<h4 id="La_respuesta">La respuesta</h4>

<p>La primera parte de la respuesta a esta petición se muestra abajo. La cabecera o header contiene información como la siguiente:</p>

<ul>
 <li>La primera linea incluye el código de respuesta <code>200 OK</code>, que nos dice que la petición ha tenido éxito.</li>
 <li>Podemos ver que la respuesta está formateada (<code>Content-Type</code>) en modo <code>text/html</code>.</li>
 <li>Podemos ver que usa también el conjunto de caracteres UTF-8 (<code>Content-Type: text/html; charset=utf-8</code>).</li>
 <li>La cabecera también nos dice lo grande que es (<code>Content-Length: 41823</code>).</li>
</ul>

<p>Al final del mensaje vemos el contenido del <strong>cuerpo</strong> (<strong>body</strong>) — que contiene el HTML real devuelto por la respuesta.</p>

<pre class="brush: html">HTTP/1.1 200 OK
Server: Apache
X-Backend-Server: developer1.webapp.scl3.mozilla.com
Vary: Accept,Cookie, Accept-Encoding
Content-Type: text/html; charset=utf-8
Date: Wed, 07 Sep 2016 00:11:31 GMT
Keep-Alive: timeout=5, max=999
Connection: Keep-Alive
X-Frame-Options: DENY
Allow: GET
X-Cache-Info: caching
Content-Length: 41823



&lt;!DOCTYPE html&gt;
&lt;html lang="en-US" dir="ltr" class="redesign no-js"  data-ffo-opensanslight=false data-ffo-opensans=false &gt;
&lt;head prefix="og: http://ogp.me/ns#"&gt;
  &lt;meta charset="utf-8"&gt;
  &lt;meta http-equiv="X-UA-Compatible" content="IE=Edge"&gt;
  &lt;script&gt;(function(d) { d.className = d.className.replace(/\bno-js/, ''); })(document.documentElement);&lt;/script&gt;
  ...
</pre>

<p>El resto de la cabecera de la respuesta incluye información sobre la respuesta (ej. cuándo se generó), el servidor, y cómo espera el explorador manejar la página (ej. la linea <code>X-Frame-Options: DENY</code> le dice que al explorador que no está permitido incrustar esta página en un {{htmlelement("iframe")}} en otro sitio).</p>

<h3 id="Ejemplo_de_peticiónrespuesta_POST">Ejemplo de petición/respuesta POST</h3>

<p>Un HTTP <code>POST</code> se realiza cuando se envía un formulario que contiene información para ser guardada en el servidor.</p>

<h4 id="La_petición_2">La petición</h4>

<p>El texto de abajo muestra la petición HTTP realizada cuando un usuario envía al sitio los detalles de un nuevo perfil. El formato de la petición es casi el mismo que en la petición <code>GET</code> del ejemplo mostrado previamente, aunque la primera linea identifica esta petición como <code>POST</code>. </p>

<pre class="brush: html">POST https://developer.mozilla.org/en-US/profiles/hamishwillee/edit HTTP/1.1
Host: developer.mozilla.org
Connection: keep-alive
Content-Length: 432
Pragma: no-cache
Cache-Control: no-cache
Origin: https://developer.mozilla.org
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Referer: https://developer.mozilla.org/en-US/profiles/hamishwillee/edit
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.8,es;q=0.6
Cookie: sessionid=6ynxs23n521lu21b1t136rhbv7ezngie; _gat=1; csrftoken=zIPUJsAZv6pcgCBJSCj1zU6pQZbfMUAT; dwf_section_edit=False; dwf_sg_task_completion=False; _ga=GA1.2.1688886003.1471911953; ffo=true

csrfmiddlewaretoken=zIPUJsAZv6pcgCBJSCj1zU6pQZbfMUAT&amp;user-username=hamishwillee&amp;user-fullname=Hamish+Willee&amp;user-title=&amp;user-organization=&amp;user-location=Australia&amp;user-locale=en-US&amp;user-timezone=Australia%2FMelbourne&amp;user-irc_nickname=&amp;user-interests=&amp;user-expertise=&amp;user-twitter_url=&amp;user-stackoverflow_url=&amp;user-linkedin_url=&amp;user-mozillians_url=&amp;user-facebook_url=</pre>

<p>La principal diferencia es que la URL no tiene parámetros. Como puedes ver, la información del formulario se codifica en el cuerpo de la petición (por ejemplo, el nombre completo del nuevo usuario se establece usando: <code>&amp;user-fullname=Hamish+Willee</code>).</p>

<h4 id="La_respuesta_2">La respuesta</h4>

<p>La respuesta a la petición se muestra abajo. El código de estado "<code>302 Found</code>" le dice al explorador que el POST ha tenido éxito, y que debe realizar una segunda petición HTTP para cargar la página especificada en el campo <code>Location</code>. La información es de lo contrario similar a la respuesta a una petición <code>GET</code>.</p>

<pre class="brush: html">HTTP/1.1 302 FOUND
Server: Apache
X-Backend-Server: developer3.webapp.scl3.mozilla.com
Vary: Cookie
Vary: Accept-Encoding
Content-Type: text/html; charset=utf-8
Date: Wed, 07 Sep 2016 00:38:13 GMT
Location: https://developer.mozilla.org/en-US/profiles/hamishwillee
Keep-Alive: timeout=5, max=1000
Connection: Keep-Alive
X-Frame-Options: DENY
X-Cache-Info: not cacheable; request wasn't a GET or HEAD
Content-Length: 0
</pre>

<div class="note">
<p><strong>Nota</strong>: Las repuestas y las peticiones HTTP mostradas en estos ejemplos fueron capturadas usando la aplicación <a href="https://www.telerik.com/download/fiddler">Fiddler</a>, pero puedes obtener información similar usando sniffers web (ej. <a href="http://web-sniffer.net/">http://web-sniffer.net/</a>) o usando extensiones del explorador como <a href="https://addons.mozilla.org/en-US/firefox/addon/httpfox/">HttpFox</a>. Puedes probarlo por tí mismo. Usa una de las herramientas enlazadas, y a continuación navega a través de un sitio y edita información del perfil para ver las diferentes peticiones y respuestas. La mayoría de los exploradores modernos también tienen herramientas que monitorizan las peticiciones de red (Por ejemplo, la herramienta <a href="/en-US/docs/Tools/Network_Monitor">Network Monitor</a> en Firefox).</p>
</div>

<h2 id="Sitios_estáticos">Sitios estáticos</h2>

<p>Un <em>sitio estático</em> es aquél que devuelve desde el servidor el mismo contenido establecido de forma fija en el código cada vez que se solicita una página en particular. De manera que si por ejemplo tienes una página sobre un producto en <code>/static/myproduct1.html</code> , a todos los usuarios se les devolverá la misma página. Si añades otro producto similar a tu sitio necesitarás añadir otra página (ej. <code>myproduct2.html</code>) etc... Esto puede llegar a ser realmente muy poco eficiente — ¿qué sucede cuando alcanzas miles de páginas de productos? Repetirías un montón de código a lo largo de cada página (la plantilla básica de la página, la estructura, etc), y si quisieras cambiar cualquier cosa de la estructura de la página — como añadir una nueva sección de "productos relacionados" por ejemplo — tendrías que cambiar cada página individualmente. </p>

<div class="note">
<p><strong>Nota</strong>: Los sitios estáticos son excelentes cuando tienes un pequeño número de páginas y quieres enviar el mismo contenido a todos los usuarios. Sin embargo pueden tener un coste de mantenimiento significante a medida que es número de páginas se hace grande.</p>
</div>

<p>Recapitulemos cómo funciona ésto, mirando otra vez el diagrama de la arquitectura de un sitio estático que vimos en el anterior artículo.</p>

<p><img alt="A simplified diagram of a static web server." src="https://mdn.mozillademos.org/files/13841/Basic%20Static%20App%20Server.png"></p>

<p>Cuando un usuario quiere navegar a una página, el explorador envía una petición HTTP <code>GET</code> especificando la URL de su página HTML. El servidor recupera el documento solicitado de su sistema de ficheros y devuelve una respuesta HTTP conteniendo el documento y un <a href="/en-US/docs/Web/HTTP/Status">código de estado de respuesta HTTP</a> "<code>200 OK</code>" (indicando éxito). El servidor podría devolver un código de estado diferente, por ejemplo "<code>404 Not Found</code>" si el fichero no está presente en el servidor, o "<code>301 Moved Permanently</code>" si el fichero existe pero ha sido redirigido a una localización diferente.</p>

<p>El servidor de un sitio estático sólo tendrá que procesar peticiones GET, ya que el servidor no almacena ningún dato modificable. Tampoco cambia sus respuestas basádonse en los datos de la petición HTTP (ej. parámetros URL o cookies). </p>

<p>Entendiendo cómo funcionan los sitios estáticos es útil sin embargo cuando se aprende programación de lado servidor, porque los sitios dinámicos gestionan las peticiones de ficheros estáticos (CSS, JavaScript, imágenes estáticas, etc.) exactamente de la misma forma.</p>

<h2 id="Sitios_dinámicos">Sitios dinámicos</h2>

<p>Un <em>sitio dinámico</em> es aquél que puede generar y devolver contenido basándose en la URL y los datos específicos de la petición (en vez de devolver siempre para una URL en particular el mismo fichero especificado en el código de forma fija). Usando el ejemplo de un sitio de productos, el servidor almacenaría "datos" del producto en una base de datos en vez de ficheros HTML individuales. Cuando se reciba una petición HTTP <code>GET</code> para un producto, el servidor determina el ID del mismo, extrae los datos de la base y construye la página HTML de la respuesta insertando los datos dentro de la plantilla HTML. Esto tiene una ventaja primordial sobre un sitio estático: </p>

<p>Usar una base de datos permite que la información del producto se almacene de forma eficiente y que se pueda ampliar, modificar y buscar fácilmente.</p>

<p>Usar plantillas HTML hace que sea muy fácil cambiar la estructura HTML, porque sólo se necesita hacer en un sólo lugar, en una única plantilla y no a lo largo de miles de páginas estáticas.</p>

<h3 id="Anatomía_de_una_petición_dinámica">Anatomía de una petición dinámica</h3>

<p>Esta sección proporciona una visión general paso a paso de un ciclo de petición y respuesta HTTP "dinámicas", construyendo con más detalle lo que vimos en el último artículo. Para "hacer cosas reales" usaremos el contexto del sitio web de un manager de equipos deportivos donde un entrenador puede seleccionar el nombre y tamaño de su equipo en un formulario HTML y obtener de vuelta una sugerencia de "mejor alineación" para el próximo partido. </p>

<p>El diagrama de abajo muestra los elementos principales del sitio web del "entrenador del equipo", junto con etiquetas numeradas de la secuencia de operaciones cuando el entrenador accede a su lista de "mejor equipo". Las partes del sitio que lo hacen dinámico son las <em>Aplicaciones Web</em> (que es como llamaremos al código del lado servidor que procesa las peticiones HTTP y devuelve respuestas HTTP), la <em>Base de Datos</em>, que contiene la información sobre los jugadores, equipos, entrenadores y sus relaciones, y las <em>Plantillas HTML</em>.</p>

<p><img alt="This is a diagram of a simple web server with step numbers for each of step of the client-server interaction." src="https://mdn.mozillademos.org/files/13829/Web%20Application%20with%20HTML%20and%20Steps.png" style="height: 584px; width: 1226px;"></p>

<p>Después de que el entrenador envíe el formulario con el nombre del equipo y el número de jugadores, la secuencia de operaciones es la siguiente:</p>

<ol>
 <li>El explorador web crea una petición HTTP <code>GET</code> al servidor usando la URL base del recurso (<code>/best</code>) y codifica el equipo y número de jugadores como parámetros URL (ej. <code>/best?team=my_team_name&amp;show=11)</code> o formando parte de un patrón URL (ej. <code>/best/my_team_name/11/</code>). Se usa una petición <code>GET</code> porque la petición sólo recoge datos (no modifica ninguno).</li>
 <li>El S<em>ervidor Web</em> detecta que la petición es "dinámica" y la reenvía a la <em>Aplicación</em> para que la procese (el servidor web determina como manejar diferentes URLs basándose en reglas de emparejamiento de patrones definidas en su configuración).</li>
 <li>La <em>Aplicación Web</em> identifica que la intención de la petición es obtener la "lista del mejor equipo" basándose en la URL (<code>/best/</code>) y encuentra el nombre del equipo y el número de jugadores requeridos a partir de la URL. La <em>Aplicación Web</em> obtiene entonces la información solicitada de la base de datos (usando parámetros "internos" adicionales que definen qué jugadores son los "mejores", y posiblemente también obteniendo la identidad del entrenador que ha iniciado sesión a partir de un cookie del lado cliente).</li>
 <li>La <em>Aplicación Web</em> crea dinámicamente una página HTML por medio de colocar los datos (de la <em>base</em>) en marcadores de posición dentro de la plantilla HTML.</li>
 <li>La <em>Aplicación Web</em> devuelve el HTML generado al explorador web (via el <em>Servidor Web</em>), junto con un código de estado HTTP de 200 ("éxito"). Si algo impide que se pueda devolver el HTML entonces la <em>Aplicación Web</em> devolverá otro código — por ejemplo "404" para indicar que el equipo no existe.</li>
 <li>El Explorador Web comenzará a continuación a procesar el HTML devuelto, enviando peticiones separadas para obtener cualquier otro fichero CSS o JavaScript que sea referenciado (ver paso 7).</li>
 <li>El Servidor Web carga ficheros estáticos del sistema de ficheros y los devuelve al explorador directamente (de nuevo, la gestión correcta de los ficheros está basada en las reglas de configuración y de emparejamiento de patrones URL).</li>
</ol>

<p>La operación de actualizar un registro de la base de datos se gestionaría de forma similar, excepto que, como para cualquier actualización de la base de datos, la petición HTTP desde el explorador debería ser codificada como petición <code>POST</code>. </p>

<h3 id="Realización_de_otros_trabajos">Realización de otros trabajos</h3>

<p>La misión de una <em>Aplicación Web</em> es recibir peticiones HTTP y devolver respuestas HTTP. Mientras que interactuar con la base datos para obtener o actualizar información son tareas muy comunes, el código puede hacer otras cosas al mismo tiempo, o no interactuar con una base de datos en absoluto.</p>

<p>Un buen ejemplo de una tarea adicional que una <em> Aplicación Web</em> podría realizar sería el envío de un correo electrónico a los usuarios para confirmar su registro en el sitio. El sito podría también realizar logging u otras operaciones.</p>

<h3 id="Devolución_de_alguna_otra_cosa_distinta_a_HTML">Devolución de alguna otra cosa distinta a HTML</h3>

<p>El código lado servidor de un sitio web no tiene que devolver fragmentos/ficheros HTML en la respuesta. Puede en vez de eso crear dinámicamente y devolver otros tipos de ficheros (texto, PDF, CSV, etc.) o incluso datos (jSON, XML, etc.).</p>

<p>La idea de devolver datos a un explorador web de forma que pueda actualizar su propio contenido dinámicamente ({{glossary("AJAX")}}) ha estado dando vueltas durante bastante tiempo. Más recientemente han llegado a ser muy populares las "apps de una sola página", donde el sitio web entero está escrito con un solo fichero HTML que es actualizado dinámicamente cuando se necesita. Los sitios web creados usando este estilo de aplicación transfieren una gran parte del coste computacional desde el servidor al explorador web, y pueden dar como resultado sitios web que se comportan mucho más como aplicaciones nativas (con una respuesta rápida "highly responsive", etc.).</p>

<h2 id="Los_frameworks_Web_simplifican_la_programación_de_lado_servidor">Los frameworks Web simplifican la programación de lado servidor</h2>

<p>Los frameworks de lado servidor hacen mucho más fácil escribir código para gestionar las operaciones descritas más arriba.</p>

<p>Una de las operaciones más importantes que realizan es proporcionar mecanismos simples para mapear las URLs de diferentes recursos/páginas a funciones para su gestión específicas. Esto hace más fácil mantener separado el código asociado con cada recurso. Esto tiene también beneficios en términos de mantenimiento, ya que puedes cambiar la URL usada para entregar una característica particular en un sitio, sin tener que cambiar la función de gestión.</p>

<p>Por ejemplo, considera el siguiente código Django (Python) que mapea dos patrones URL a dos funciones de visualización. El primer patrón asegura que una petición HTTP con una URL de  <code>/best</code> sea pasada a la función llamada <code>index()</code> en el módulo <code>views</code>. En cambio, una petición que tiene el patrón "<code>/best/junior</code>", se pasará a la función de visualización <code>junior()</code>.</p>

<pre class="brush: python"># file: best/urls.py
#

from django.conf.urls import url

from . import views

urlpatterns = [
    # example: /best/
    url(r'^$', views.index),
    # example: /best/junior/
    url(r'^junior/$', views.junior),
]</pre>

<div class="note">
<p><strong>Nota</strong>: El primer parámetro en las funciones <code>url()</code> puede parecer un poco extraño (ej. <code>r'^junior/$'</code>) porque usan una técnica de emparejamiento de patrones llamada "expresiones regulares" ("regular expressions", RegEx, o RE). No necesitas saber cómo funcionan las expresiones regulares en este momento, tan sólo que nos permiten emparejar patrones en el URL (en vez de los valores insertados en el código de forma fija que veíamos más arriba) y los usan como parámetros en nuestras funciones de visualización. Como ejemplo, una RegEx simple podría decir "empareja una simple letra mayúscula, seguida de entre 4 y 7 letras minúsculas."</p>
</div>

<p>El framework web también hace fácil a una función de visualización extraer información de la base de datos. La estructura de nuestros datos está definida en modelos, que son las clases Python que definen los campos que serán almacenados en la base de datos subyacente. Si tenemos un modelo llamado <em>Team</em> con un campo de "<em>team_type</em>" podemos usar un query de sintaxis simple para recuperar todos los equipos que son de un tipo particular.</p>

<p>Los ejemplos de abajo recuperan una lista de todos los equipos que tienen el <code>team_type</code> de "junior" exacto (teniendo en cuenta la capitalización, mayúsculas o minúsculas) — nota de formato: el nombre del campo (<code>team_type</code>) seguido de un guión bajo doble, y a continuación el tipo de emparejamiento a usar (en este caso <code>exact</code>). Hay muchos otros tipos de emparejamiento y podemos encadenarlos fácilmente. Podemos controlar el orden y número de resultados que se devuelven. </p>

<pre class="brush: python">#best/views.py

from django.shortcuts import render

from .models import Team


def junior(request):
    list_teams = Team.objects.filter(team_type__exact="junior")
    context = {'list': list_teams}
    return render(request, 'best/index.html', context)
</pre>

<p>Después de que la función <code>junior()</code> obtenga la lista de equipos junior, llama a la función <code>render()</code>, pasándole el <code>HttpRequest</code> original,  una plantilla HTML, y un objeto "contexto" que define la información a ser incluida en la plantilla. La función <code>render()</code> es una función de conveniencia que genera HTML usando un contexto y una plantilla HTML, y devuelve un objeto <code>HttpResponse</code>.</p>

<p>Obviamente los frameworks web pueden ayudarte con un monton de otras tareas. Debatiremos sobre un montón más de beneficios y opciones de frameworks web en el próximo artículo.</p>

<h2 id="Sumario">Sumario</h2>

<p>En este punto deberías tener una buena visión general de las operaciones que el código de lado servidor tiene que realizar, y conocer algunas de las formas en que un framework web de lado servidor las puede hacer más fáciles.</p>

<p>En el módulo siguiente te ayudaremos a elegir el mejor Framework Web para tu primer sitio.</p>

<p>{{PreviousMenuNext("Learn/Server-side/First_steps/Introduction", "Learn/Server-side/First_steps/Web_frameworks", "Learn/Server-side/First_steps")}}</p>

<p> </p>

<h2 id="En_este_módulo">En este módulo</h2>

<ul>
 <li><a href="/en-US/docs/Learn/Server-side/First_steps/Introduction">Introducción al lado servidor</a></li>
 <li><a href="/en-US/docs/Learn/Server-side/First_steps/Client-Server_overview">Visión general Cliente-Servidor</a></li>
 <li><a href="/en-US/docs/Learn/Server-side/First_steps/Web_frameworks">Frameworks Web de lado servidor</a></li>
 <li><a href="/en-US/docs/Learn/Server-side/First_steps/Website_security">Seguridad Web</a></li>
</ul>

<p> </p>