Entendiendo el internet apátrida [cerrado]

Estoy pasando de ser un desarrollador de escritorio a un desarrollador web, y tengo problemas para entender por qué HTTP no tiene estado. ¿Cuáles son las razones para ello? ¿De qué maneras un desarrollador de escritorio como yo puede hacer la transición a un entorno de desarrollo sin estado?

Esta es la mejor explicación de Internet sin estado que he visto:

Cómo le expliqué REST  a mi esposa
http://www.looah.com/source/view/2284

Esposa: ¿Quién es Roy Fielding?

Ryan: un chico. Es listo.

Esposa: oh? ¿Qué hizo él?

Ryan: Ayudó a escribir los primeros servidores web y luego hizo un montón de investigación explicando por qué la web funciona de la manera en que funciona. Su nombre está en la especificación del protocolo que se utiliza para obtener páginas de servidores a su navegador.

Esposa: ¿Cómo funciona?

Ryan: ¿ La web?

Esposa: si .

Ryan: Hmm. Bueno, todo es realmente asombroso. Y lo curioso es que todo está muy infravalorado. El protocolo del que hablaba, HTTP, es capaz de todo tipo de cosas interesantes que las personas ignoran por alguna razón.

Esposa: ¿ Te refieres a http como el comienzo de lo que escribo en el navegador?

Ryan: si . Esa primera parte le dice al navegador qué protocolo usar. Las cosas que escribe allí son uno de los avances más importantes en la historia de la informática.

Esposa: ¿por qué?

Ryan: Porque es capaz de describir la ubicación de algo en cualquier parte del mundo desde cualquier parte del mundo. Es la base de la web. Puedes pensarlo como coordenadas GPS para conocimiento e información.

Esposa: ¿ Para páginas web?

Ryan: Para cualquier cosa realmente. Ese tipo, Roy Fielding, habla mucho sobre lo que esas cosas señalan en esa investigación de la que estaba hablando. La web está construida sobre un estilo arquitectónico llamado REST. REST proporciona una definición de un recurso, que es a lo que apuntan esas cosas.

Esposa: ¿ Una página web es un recurso?

Ryan: algo así . Una página web es una representación de un recurso. Los recursos son solo conceptos. URL: las cosas que escribe en el navegador ...

Esposa: Sé lo que es una URL ...

Ryan: Oh, cierto. Esos le dicen al navegador que hay un concepto en alguna parte. Un navegador puede ir a pedir una representación específica del concepto. Específicamente, el navegador solicita la representación de la página web del concepto.

Esposa: ¿Qué otro tipo de representaciones hay?

Ryan: En realidad, las representaciones son una de estas cosas que no se usan mucho. En la mayoría de los casos, un recurso tiene una sola representación. Pero esperamos que las representaciones se usen más en el futuro porque hay un montón de nuevos formatos apareciendo por todas partes.

Esposa: ¿Como qué?

Ryan: Hmm. Bueno, existe este concepto que la gente llama Servicios web. Significa muchas cosas diferentes para muchas personas diferentes, pero el concepto básico es que las máquinas podrían usar la web al igual que las personas.

Esposa: ¿Es esta otra cosa del robot?

Ryan: No, en realidad no. No quiero decir que las máquinas estén sentadas en el escritorio y navegando por la web. Pero las computadoras pueden usar esos mismos protocolos para enviarse mensajes entre ellos. Lo hemos estado haciendo durante mucho tiempo, pero ninguna de las técnicas que utilizamos hoy funciona bien cuando se necesita poder hablar con todas las máquinas del mundo entero.

Esposa: ¿Por qué no?

Ryan: Porque no fueron diseñados para ser utilizados así. Cuando Fielding y sus amigos comenzaron a construir la web, la principal preocupación era poder hablar con cualquier máquina en cualquier parte del mundo. La mayoría de las técnicas que utilizamos en el trabajo para hacer que las computadoras se comuniquen entre sí no tenían esos requisitos. Solo necesitaba hablar con un pequeño grupo de máquinas.

Esposa: ¿ Y ahora necesitas hablar con todas las máquinas?

Ryan: Sí, y más. Necesitamos poder hablar con todas las máquinas sobre todas las cosas que están en todas las otras máquinas. Por lo tanto, necesitamos alguna forma de hacer que una máquina informe a otra máquina sobre un recurso que podría estar en otra máquina.

Esposa: Que?

Ryan: Digamos que estás hablando con tu hermana y ella quiere pedir prestada la barredora o algo así. Pero no lo tienes, tu mamá lo tiene. Entonces le dices a tu hermana que lo obtenga de tu mamá. Esto sucede todo el tiempo en la vida real y sucede todo el tiempo cuando las máquinas también comienzan a hablar.

Esposa: Entonces, ¿cómo se dicen las máquinas entre sí dónde están las cosas?

Ryan: La URL, por supuesto. Si todo lo que las máquinas necesitan hablar tiene una URL correspondiente, ha creado la máquina equivalente a un sustantivo. Que tú, yo y el resto del mundo hayamos acordado hablar sobre sustantivos de cierta manera es bastante importante, ¿eh?

Esposa: si .

Ryan: Las máquinas no tienen un sustantivo universal, por eso apestan. Cada lenguaje de programación, base de datos u otro tipo de sistema tiene una forma diferente de hablar sobre sustantivos. Es por eso que la URL es tan importante. Permite que todos estos sistemas se cuenten entre sí sobre los sustantivos de cada uno.

Esposa: Pero cuando estoy mirando una página web, no pienso en eso así.

Ryan: nadie lo hace. Excepto Fielding y un puñado de otras personas. Es por eso que las máquinas todavía apestan.

Esposa: ¿Qué pasa con los verbos, pronombres y adjetivos?

Ryan: Es curioso que lo hayas preguntado porque ese es otro gran aspecto de REST. Bueno, los verbos son de todos modos.

Esposa: Solo estaba bromeando.

Ryan: Fue una broma divertida, pero en realidad no es una broma en absoluto. Los verbos son importantes. Hay un concepto poderoso en programación y teoría de CS llamado polimorfismo. Esa es una manera geek de decir que a diferentes sustantivos se les puede aplicar el mismo verbo.

Esposa: No lo entiendo.

Ryan: Bueno ... mira la mesa de café. ¿Qué son los sustantivos? Vaso, bandeja, periódico, control remoto. Ahora, ¿qué cosas puedes hacer con todas estas cosas?

Esposa: No lo entiendo ...

Ryan: Puedes conseguirlos, ¿verdad? Puedes recogerlos. Puedes derribarlos. Puedes quemarlos. Puedes aplicar esos mismos verbos exactos a cualquiera de los objetos que están allí.

Esposa: Ok ... entonces?

Ryan: Bueno, eso es importante. ¿Qué pasaría si en lugar de que yo pueda decirte "toma la taza" y "toma el periódico" y "toma el control remoto"; ¿Qué pasaría si en su lugar necesitáramos inventar verbos diferentes para cada uno de los sustantivos? No podía usar la palabra "get" universalmente, sino que tenía que pensar una nueva palabra para cada combinación de verbo / sustantivo.

Esposa: ¡Guau! Eso es raro.

Ryan: Sí lo es. Nuestros cerebros son lo suficientemente inteligentes como para saber que los mismos verbos se pueden aplicar a muchos sustantivos diferentes. Algunos verbos son más específicos que otros y se aplican solo a un pequeño conjunto de sustantivos. Por ejemplo, no puedo conducir una taza y no puedo beber un automóvil. Pero algunos verbos son casi universales como GET, PUT y DELETE.

Esposa: No puedes ELIMINAR una taza.

Ryan: Bueno, está bien, pero puedes tirarlo. Esa fue otra broma, ¿verdad?

Esposa: si .

Ryan: De todos modos, HTTP, este protocolo creado por Fielding y sus amigos, se trata de aplicar verbos a los sustantivos. Por ejemplo, cuando va a una página web, el navegador realiza un HTTP GET en la URL que ingresa y regresa una página web.

Las páginas web suelen tener imágenes, ¿verdad? Esos son recursos separados. La página web solo especifica las URL de las imágenes y el navegador va y realiza más GET HTTP en ellas hasta que se obtienen todos los recursos y se muestra la página web. Pero lo importante aquí es que tipos muy diferentes de sustantivos pueden ser tratados de la misma manera. Si el sustantivo es una imagen, texto, video, un mp3, una presentación de diapositivas, lo que sea. Puedo OBTENER todas esas cosas de la misma manera dada una URL.

Esposa: Parece que GET es un verbo bastante importante.

Ryan: lo es. Especialmente cuando estás usando un navegador web porque los navegadores simplemente OBTENEN cosas. No hacen muchos otros tipos de interacción con los recursos. Esto es un problema porque ha llevado a muchas personas a suponer que HTTP es solo para OBTENER. Pero HTTP es en realidad un protocolo de propósito general para aplicar verbos a sustantivos.

Esposa: genial. Pero todavía no veo cómo esto cambia nada. ¿Qué tipo de sustantivos y verbos quieres?

Ryan: Bueno, los sustantivos están ahí pero no en el formato correcto.

Piensa en cuando estás navegando por amazon.com buscando cosas para comprarme para Navidad. Imagina cada uno de los productos como sustantivos. Ahora, si estuvieran disponibles en una representación que una máquina pudiera entender, podría hacer muchas cosas buenas.

Esposa: ¿Por qué una máquina no puede entender una página web normal?

Ryan: Porque las páginas web están diseñadas para que las personas las entiendan. Una máquina no se preocupa por el diseño y el estilo. Las máquinas básicamente solo necesitan los datos. Idealmente, cada URL tendría una representación legible por humanos y una representación legible por máquina. Cuando una máquina OBTENGA el recurso, le pedirá uno legible por la máquina. Cuando un navegador OBTENGA un recurso para un humano, le pedirá uno legible.

Esposa: ¿Entonces la gente tendría que hacer formatos de máquina para todas sus páginas?

Ryan: Si fuera valioso.

Mira, hemos estado hablando de esto con mucha abstracción. ¿Qué tal si tomamos un ejemplo real? Eres un maestro: en la escuela apuesto a que tienes un gran sistema informático, o tres o cuatro sistemas informáticos más probables, que te permiten administrar a los estudiantes: en qué clases están, qué calificaciones están obteniendo, contactos de emergencia, información sobre los libros que enseña, etc. Si los sistemas están basados ​​en la web, entonces probablemente haya una URL para cada uno de los sustantivos involucrados aquí: estudiante, maestro, clase, libro, sala, etc. Ahora mismo, obteniendo la URL el navegador te da una página web. Si hubiera una representación legible por máquina para cada URL, sería trivial conectar nuevas herramientas al sistema porque toda esa información sería consumible de una manera estándar. También facilitaría un poco la comunicación entre cada uno de los sistemas. O bien, podría construir un sistema estatal o nacional que pudiera hablar con cada uno de los sistemas escolares individuales para obtener puntajes de exámenes. Las posibilidades son infinitas.

Cada uno de los sistemas obtendría información el uno del otro utilizando un simple HTTP GET. Si un sistema necesita agregar algo a otro sistema, usaría una POST HTTP. Si un sistema desea actualizar algo en otro sistema, utiliza un PUT HTTP. Lo único que queda por descubrir es cómo deberían verse los datos.

Esposa: ¿Entonces esto es en lo que usted y toda la gente de la computadora están trabajando ahora? ¿Decidir cómo deberían verse los datos?

Ryan: Tristemente no. En cambio, la gran mayoría está ocupada escribiendo capas de especificaciones complejas para hacer estas cosas de una manera diferente que no es tan útil o elocuente. Los sustantivos no son universales y los verbos no son polimórficos. Estamos lanzando décadas de uso de campo real y técnica probada y comenzando de nuevo con algo que se parece mucho a otros sistemas que han fallado en el pasado. Estamos usando HTTP, pero solo porque nos ayuda a hablar menos con nuestra red y con las personas de seguridad. Estamos intercambiando simplicidad por herramientas y magos llamativos.

Esposa: ¿por qué?

Ryan: No tengo idea.

Esposa: ¿Por qué no dices algo?

Ryan: Quizás lo haga.

¿Cómo crees que sería posible almacenar el estado de miles de millones de miles de millones de miles de millones de conexiones? :) Por lo tanto, solo almacena el estado donde sea necesario, en sesiones.

Por cierto: HTTP no es sin conexión.

Como desarrollador de escritorio, puede sentirse más cómodo con experiencias ricas de IU. Pasar a la web puede parecer un paso atrás. En el mundo web, hay menos libertad de creatividad y puede darte una sensación de restricción. ¡No dejes que eso te deprima! Hay varias cosas por ahí que pueden ayudarlo a hacer la transición y aquí hay una breve lista de ellas:

1. El estado se puede compartir, pero con frecuencia se mantiene en el servidor y se hace referencia a él mediante tokens como identificadores de sesión, parámetros de URL, campos ocultos o valores de cookies.
2. Los modelos sin estado son muy adecuados para el procesamiento de transacciones. Intente construir su modelo de tal manera que pueda reducir la cantidad de estado requerido. Los principios ACID del procesamiento de transacciones pueden ayudarlo a lograr esto.
3. Familiarícese con el patrón MVC (si aún no lo está). Esto ayudará a mejorar su diseño al mantener una separación de preocupaciones. Algunos marcos populares como Struts (Java) y MVC (.NET) se basan en este concepto.
4. Considere usar un complemento como Java , Flash o Silverlight para experiencias de interfaz de usuario súper ricas. Para experiencias semi-ricas, considere el uso de bibliotecas populares basadas en script java como JQuery o AJAX .

¡Feliz programación!

Porque hubo un tiempo en el que no había millones y millones de páginas web. Porque hubo un tiempo en que solo las universidades y las instalaciones de investigación tenían un par de páginas. Hubo un tiempo en que no había banda ancha, y http se comunicaba con 1200 módems en baudios colocados encima de los teléfonos de escritorio. Hubo un momento en que las "aplicaciones web ricas" habrían requerido, en su opinión, una cantidad ridícula de ancho de banda. Y recuerde, TCP / IP se creó porque la Internet temprana era muy poco confiable.

HTTP 1.0 existía a principios de la década de 1990. Piense en cómo era Internet entonces y por qué lo diseñaron de la manera en que lo hicieron.

Todo evolucionó. Internet existía antes que los navegadores web y la Web. Era una olla burbujeante de ftp, telnet, gopher, ping, dedo y algunos otros bits y bobs. El primer navegador web, Mosaic (creo que fue hace mucho tiempo, 1991 creo que estaba en la universidad) actuó como una especie de mezcla entre ftp y un visor de documentos. La magia sucedió en el sentido de que podría tener enlaces en el documento que crearían un nuevo documento.

Toda la interactividad que hemos desarrollado en el transcurso de los siguientes 20 años. Tampoco fue una evolución feliz. Tuvimos la guerra de los navegadores, IE y Netscape lo rechazaron por el control de los estándares (un poco de simplificación;)), y varios otros terceros comenzaron a introducir complementos para permitir un contenido rico. Java iba a ser la bala mágica y, por supuesto, Flash. ¿Alguien recuerda los complementos VRML que prometían mundos en 3D y entregaron exactamente media docena de modelos en 3D de modelos de Star Wars?

Me dejé llevar un poco hacia el final, pero entiendes la idea :)

Las razones principales tienen que ver con una combinación de lo que acedemia creía que era el propósito de HTTP, y por razones de escalabilidad. HTML fue originalmente diseñado para compartir información o tesis a través de los límites académicos. Era texto puramente estilizado. No fue hasta que el primer navegador le permitió mostrar imágenes que la gente comenzó a pensar más allá de ese modelo.

Las siguientes consideraciones solidificaron la decisión apátrida:

• La interacción típica iba a ser una descarga rápida y lectura. Durante el retraso hasta la próxima solicitud, el socket estará inactivo.
• Los sockets ocupan valiosos recursos del sistema. Si no tuviéramos que mantener una conversación como lo haría con SMTP, puede hacer mucho para que una máquina maneje miles de clientes.
• Ya aprendieron lecciones valiosas de la administración de cuentas de shell remotas, NFS, SMTP y otros protocolos de conexión con estado.

A medida que las páginas web se volvieron más complejas e incluyeron muchos gráficos y hojas de estilo, HTTP fue enmendado con la bandera "keep-alive". Eso mantendría el socket activo y permitiría al cliente solicitar varios recursos con la misma conversación.

Teniendo en cuenta el modelo de uso actual de Internet, la decisión original sigue siendo válida. A veces puede ser inconveniente, pero varias interacciones pequeñas y cuantificadas con un servidor escalan mejor que los sockets inactivos.

Si te refieres a navegadores bidireccionales.

Razones de seguridad.

Por ejemplo SPAM !.

Llevando la comunicación bidireccional en la web al siguiente nivel

De lo contrario, Internet ejecuta TCP / IP (dos protocolos) y UDP.

El protocolo de control de transmisión(TCP) es uno de los protocolos principales de Internet Protocol Suite. TCP es uno de los dos componentes originales de la suite, que complementa el Protocolo de Internet (IP) y, por lo tanto, toda la suite se conoce comúnmente como TCP / IP. TCP proporciona el servicio de intercambio de datos directamente entre dos hosts en la misma red, mientras que IP maneja el direccionamiento y el enrutamiento de mensajes en una o más redes. En particular, TCP proporciona una entrega confiable y ordenada de una secuencia de bytes de un programa en una computadora a otro programa en otra computadora. TCP es el protocolo en el que confían las principales aplicaciones de Internet, aplicaciones como la World Wide Web, el correo electrónico y la transferencia de archivos. Otras aplicaciones, que no requieren un servicio confiable de flujo de datos,

El protocolo de internet(IP) es el principal protocolo de comunicaciones utilizado para retransmitir datagramas (paquetes) a través de una red interna utilizando Internet Protocol Suite. Responsable de enrutar paquetes a través de los límites de la red, es el protocolo principal que establece Internet. IP es el protocolo principal en la capa de Internet de Internet Protocol Suite y tiene la tarea de entregar datagramas del host de origen al host de destino únicamente en función de sus direcciones. Para este propósito, IP define métodos y estructuras de direccionamiento para la encapsulación de datagramas. Históricamente, IP era el servicio de datagramas sin conexión en el Programa de Control de Transmisión original introducido por Vint Cerf y Bob Kahn en 1974, siendo el otro el Protocolo de Control de Transmisión (TCP) orientado a la conexión. Por lo tanto, el conjunto de protocolos de Internet a menudo se conoce como TCP / IP.

En una aplicación de escritorio, se supone que el usuario realiza algunas series de tareas, con un inicio y un final definidos. En una aplicación de este tipo, tiene sentido (no mucho, en realidad) que los usuarios inicien sesión en cualquier servidor que proporcione sus datos y permanezcan conectados hasta que terminen.

Las interacciones web no siguen (típicamente) el mismo modelo. En un sitio de comercio electrónico, por ejemplo, un usuario puede llegar a una descripción del producto como resultado de una búsqueda en Google e inmediatamente abandonar esa página para ver la oferta de otro sitio del mismo producto. O puede comenzar el proceso de pago, luego decidir que el producto es demasiado costoso y abandonarlo a la mitad. La idea básica de "hipertexto" implica la capacidad y la expectativa de saltar de un lugar a otro.

Las conexiones permanentes consumen recursos. Quizás solo un socket de red, quizás un grupo de consultas de bases de datos analizadas; Todo depende de la aplicación. Dado un usuario que puede desaparecer en cualquier momento, no tiene mucho sentido mantener esos recursos comprometidos.

En la práctica, no hay necesidad real de que el usuario tenga una conexión permanente. La aplicación web mantiene conexiones a los recursos (p. Ej., Base de datos) que necesita y los comparte entre todas las solicitudes de los usuarios. El marco de la aplicación web proporciona sesiones, que son lugares de tiempo limitado para almacenar datos por usuario para diferentes solicitudes. Lo único que no puede hacer (fácilmente) es tener transacciones controladas por el cliente de larga duración, pero esa es una mala idea incluso en una aplicación que mantiene conexiones.

Internet no es necesariamente apátrida, de hecho cuando observa Java EE, tienen EJB con estado y EJB sin estado.

La razón principal por la que los desarrolladores recomiendan usar una arquitectura sin estado es debido a la escalabilidad. Imagine tratar de mantener el estado de todos sus usuarios una vez que agregue y descarte servidores para admitir su tráfico.

Realmente no es difícil desarrollar una arquitectura sin estado. El punto principal es mantener el menor estado posible (generalmente una identificación de usuario, preferiblemente en una cookie) y cambiar la base de datos según sea necesario.

Creo que comenzó de esa manera y siguió siendo así. Ahora que hay tanta infraestructura construida a su alrededor, es imposible cambiarla.

Quizás comenzó sin estado porque las conexiones eran menos confiables al principio, y también el ancho de banda era más pequeño. Si no tiene muchas conexiones activas, puede manejar más tráfico más fácilmente.

Edite o deje un comentario si tiene mejor información, o mejor aún, ¡publique su propia respuesta!

Es porque los servidores proporcionan un servicio (está en el nombre). Hace una solicitud y recibe respuestas, eso es todo.

Con respecto a hacer una transición al desarrollo web, creo que ASP.NET Web Forms lo hará de una manera más comprensible para usted, pero eso es solo porque oculta lo que realmente sucede bajo capas de abstracción.

Se puede entender mucho analizando el nombre de HTTP (Protocolo de transferencia de hipertexto). Nunca fue diseñado para ser un protocolo de interfaz de usuario rico. La idea original era compartir documentos con enlaces entre ellos. Le pido un documento, usted responde con una copia de ese documento.

Originalmente HTTP solo tenía un verbo GET. En ese sentido, fue diseñado para contenido estático. ¿Por qué necesita un estado cuando todo lo que está haciendo es solicitar un documento que alguien está compartiendo? Y es por eso que HTTP no tiene estado ... debido a sus orígenes.