Conceptos de ASP.NET : Conceptos Web

Patrones utilizados en ASP.NET:

Entre los patrones utilizados en ASP.NET podemos encontrar dos principales : MVC y MVVM.

Patrón MVC (Model-View-Controller)

El patrón MVC es un patrón de arquitectura de software que separa la representación de  la información de la interacción del usario con la misma.

Las partes que conforman este patrón son :

1. El Modelo: consiste en datos de aplicación, reglas de negocio,lógica y funciones. Este le notifica a sus vistas y controladores asociados cuando ocurre un cambio en su estado. Esta notificación permite a las vistas producir una salida, y a los controladores cambiar la disponibilidad de los comandos.
2. La Vista: puede ser cualquier representación visible de los datos, como una gráfica o un diagrama. Esta le pide la información necesaria al modelo para presentar la salida al usuario
3. El Controlador : es el encargado de manejar la entrada, convirtiendola en comandos para la el modelo o la vista.

Patrón MVVM (Model-View-ViewModel)

Es un patrón arquitectural usado en ingeniería de software que se origina en Microsoft como una especialización del modelo MVC introducido por Martin Fowler. Basado extensamente en patrón MVC, el MVVM está dirigido a plataformas de desarrollo de UIs que soporten programación conducida por eventos (event-driven programming), como HTML5, Windows Presentation Foundation (WPF), Silverlight y el framework ZK.

Herramientas utilizadas en ASP .NET :

JavaScript

Es un lenguaje de scripting interpretado, multi-paradigma (soporta OOP, Programación Imperativa y Programación Funcional), basado en prototipos que es dinámico y débilmente tipado. Su sintaxis es influenciada por C y copia muchos nombres y convenciones de JavaScript. Fue lanzado en 1996 por Netscape Communication, dentro de su navegador Netscape Navigator 2.0

AJAX (Asynchronous JavaScript and XML)

Es un grupo de técnicas de desarrollo web interrelacionadas utilizadas del lado del cliente (client-side) para crear aplicaciones web asíncronas. Con AJAX, las aplicaciones web pueden enviar y recibir datos de un servidor, asíncronamente (en segundo plano) sin interferir con la visualización y comportamiento de la página existente. A pesar de su nombre, el uso de XML no es requerido, en su lugar se utiliza JSON y las peticiones no necesitan ser asíncronas.

En el artículo que acuña el término AJAX, Jesse James Garret explica que las siguientes tecnologías son incorporadas: 

• HTML y CSS, para la representación.
• El Document Object Model (DOM) para la presentación dinámica e interacción de los datos.
• XML para el intercambio de datos, y XSLT para su manipulación.
• El Objeto XMLHttpRequest para la comunicación asíncrona.
• JavaScript para unir todas estas tecnologías.

Sin embargo, JSON ha desplazado el uso de XML y, por tanto, XSLT.

jQuery

Es una librería multi-plataforma diseñada para simplificar el client-side scripting de HTML.Su síntaxis está diseñada para que sea fácil navegar por un documento, seleccionar elementos del DOM, crear animaciones, manejar eventos, crear aplicaciones AJAX,entre otros usos. También permite a los desarroladores crear plugins. Fue lanzado en 2006 por Jhon Resig.

REST (Representational State Transfer)

Es un estilo de arquitectura de software para sistemas distribuidos como la WWW (World Wide Web) y es uno de los modelos de diseño de web API predominantes.

El término REST fue introducido y definido en el 2000 por Roy Fielding, uno de los principales autores de las especificaciones 1.0 y 1.1 del Hypertext Transfer Protocol (HTTP) y fue desarrollado por por el el W3C Technical Architecture Group (TAG) en paralelo con HTTP/1.1.

REST describe las siguientes 6 restricciones o reglas (constraints) aplicadas a la arquitectura, mientras dejan la implementación de los componentes individuales libres :

1 - Cliente/Servidor 

Una interfaz uniforme separa los clientes de los servidores. La separación de preocupaciones significan que, por ejemplo, los clientes no tienen que preocuparse por el almacenamiento de datos, la cual queda a discreción de cada servidor, de manera que la portabilidad del cliente es mejorada. 

Los servidores no tienen que preocuparse de la interfaz o estado de usuario, de manera que los servidores son mas simples y escalables. Los servidores y clientes pueden ser cambiados y reemplazados independientemente, siempre y cuando la interfaz entre ellos no sea alterada.

2 - Sin estado (Stateless)

La comunicación entre cliente y servidor se ve limitada además porque ningún contexto de cliente se debe almacenar en el servidor entre las solicitudes. Cada petición de cualquier cliente contiene toda la información necesaria para atender la solicitud, y cualquier estado de sesión se llevará a cabo en el cliente.

3 - Cacheable

Como en la World Wide Web, los clientes pueden almacenar en caché las respuestas. Las respuestas deben por lo tanto, de manera implícita o explícita, se definirse como almacenables en caché, o no, para evitar que los clientes puedan reutilizar datos obsoletos o inadecuados en respuesta a otras peticiones. El cacheo bien manejado elimina parcial o completamente algunas interacciones cliente-servidor, mejorando además la escabilidad y rendimiento.

4 - Sistema de Capas (Layered System)

Un cliente no puede decir ordinariamente si está conectado directamente al servidor final, o a un intermediario a lo largo del camino. Servidores intermediarios pueden mejorar la escalabilidad del sistema, permitiendo el equilibrio de carga y proporcionando caches compartidas. También pueden hacer cumplir las políticas de seguridad.

5 - Código bajo demanda (opcional)

Los servidores pueden temporalmente extender o personalizar la funcionalidad de un cliente mediante la transferencia de código ejecutable. Ejemplos de esto incluyen componentes compilados como Java applets y scripts client-side como JavaScript.

6 - Interfaz Uniforme

Tener una interfaz uniforme entre los clientes y los servidores simplifica y desacopla la arquitectura, lo que hace que cada parte pueda desarrollarse independientemente.

Un servicio que cumpla con todos los requisitos anteriores, se dice que es RESTful, pero si viola alguno no puede ser considerado como tal.

RESTful Web API

Una RESTful Web API (también llamado RESTful web service) es una web API implementada utilizando los principios HTTP y REST. Es una colección de recursos con cuatro aspectos definidos:

•   La URI base para la web API, como htt://ejemplo.com/recursos/
• El Content-type o MIME de los datos soportados por la web API. Generalmente se utiliza JSON.
• El conjunto de operaciones soportados por la web API usando verbos HTTP (GET,POST,PUT,DELETE).
• La API debe ser hypertext driven.

MEGA, Facebook, Twitter,Amazon,Yahoo,entre otros ofrecen una API para desarroladores basada en REST.

Conceptos de ASP.Net : Métodos HTTP

• Métodos HTTP

Los metodos que forman parte del Hyper-Text Transfer Protocol (HTTP) son 6 :

1. OPTIONS:  Este método representa una petición (request) de información de las opciones de comunicación disponibles en la cadena request/response identificada por el Request-URI. Este método permite al cliente determinar las opciones y/o requerimientos asociados a un recurso, o las capacidades del servidor.
2. GET:   El método GET retorna cualquier información (en forma de una entidad) que esté identificada por el Request-URI. Si el Request-URI se refiere a un proceso de producción de datos, entonces los datos producidos serán retornados como una entidad en la respuesta y no el texto del proceso, a menos que el texto sea la salida del proceso.
3. HEAD:   El método HEAD es idéntico al método GET, excepto que el servidor NO DEBE retornar un message-body en la respuesta. La metainformación contenida en las cabezeras (headers) HTTP en respuesta a una petición HEAD DEBE ser idéntica a la información enviada en respuesta a una petición GET. Este método puede ser utilizado para obtener metainformación sobre la entidad implicada en la petición sin transferir la entidad como tal.
4. POST:   El método POST es utilizado para pedir que el servidor de origen acepte la entidad adjunta en la petición como un nuevo subordinado del recurso identificado por el Request-URI en la Línea de Petición (Request-Line). El POST está diseñado como un método uniforme para cubrir las siguientes functiones:
   • Anotación de recursos existentes
   • Enviar un mensaje a un boletín, grupo de noticias, lista de correo o un un grupo similar de artículos
   • Proveer un bloque de datos, como el resultado de enviar un formulario, a un proceso manejador de datos
   • Extender una base de datos a través de una operacción de anexado (append)
   La función real realizado por el método POST se determina por el servidor y es por lo general depende de la Request-URI. La entidad publicado está subordinada a la URI de la misma manera que un archivo está subordinado a un directorio que lo contiene, un artículo de noticias está subordinado a un grupo de noticias al cual está publicado, o un registro está subordinada a una base de datos. La acción realizada por el método POST podría no dar lugar a un recurso que pueda ser identificado por un URI. En este caso, o bien 200 (OK) o 204 (Sin contenido) es el estado de la respuesta apropiada, en función de si la respuesta incluye una entidad que describe el resultado o no. Si el recurso se ha creado en el servidor de origen, la respuesta debe ser 201 (Created) y contener una entidad que describa el estado de la solicitud y se refiera al nuevo recurso, y una cabecera Location.
5. PUT:   El método PUT pide que la entidad adjunta sea almacenado bajo el Request-URI suministrado. Si la Request-URI se refiere a un recurso ya existente, la entidad adjunta DEBE ser considerada como una versión modificada de la que reside en el servidor de origen. Si el Request-URI no apunta a un recurso existente, y el URI puede ser definido como un nuevo recurso por el agente de usuario que solicita, el servidor de origen puede crear el recurso con el URI. Si se crea un nuevo recurso, el servidor de origen debe informar al agente de usuario a través de la Respuesta 201 (Created). Si se modifica un recurso existente, SE DEBE enviar una respuesta ya sea con el código 200 (OK) o 204 (No Content) para indicar la finalización con éxito de la solicitud. Si el recurso no se puede crear o modificar con el Request-URI, se debe dar una respuesta de error apropiado que refleje la naturaleza del problema. El destinatario de la entidad no debe ignorar cualquier encabezado Content-* (por ejemplo, Content-Range) que no entienda o implemente y DEBE devolver una respuesta 501 (Not Implemented) en esos casos.
6. DELETE:   El método DELETE pide que el servidor de origen elimine el recurso identificado por el Request-URI. Este método puede ser anulado por interveción humano (u otros medios) en el servidor de origen. No se le puede asegurar al cliente que la operación se haya llevado a cabo, aún si código de estado retornado por el servidor de origen indica que la acción ha sido completada sastifactoriamente. Una respuesta sastifactoria DEBE ser 200 (OK) si la respuesta incluye una entidad describiendo el estado, 202 (Accepted) si la acción todavía no ha sido promulgada, o 204 (No content) si la acción ha sido promulgada pero la respuesta no incluye una entidad.
7. TRACE: &nbps; El método TRACE es utilizado para invocar un loop-back remoto desde la capa de aplicación del mensaje de petición. El recipiente final de la petición DEBE reflejar el mensaje devuelto al cliente como el cuerpo de entidad de una respuesta 200 (OK).El método TRACE permite al cliente ver que está siendo recibido al otro lado de la cadena de petición y usar esos datos para pruebas o diagnóstico de información.
8. CONNECT: Este método se para conectarse a un proxy que puede convertirse dinámicamente en un túnel (por ejemplo, SSL Tunneling).