Diferencias

Muestra las diferencias entre dos versiones de la página.

--- code:best-practices [2010/07/05 18:46]
alfred
+++ — (actual)
@@ Línea 1: / Línea 1: @@
-====== Codificando ======
-Conceptos que hay que tener en cuenta a la hora de programar.
-===== Programación declarativa =====
-El código imperativo describe **cómo** se hace algo, mientras el declarativo describe **qué** se está haciendo. \\
-La programación declarativa expresa la lógica sin describir un flujo (if, bucles...). \\ \\
-El código siguiente es imperativo:
-<code csharp>
-using System;
-class Example
-{
-    static void Main()
-    {
-        Int32 sum = 0;
-        for (Int32 i = 0; i < 100; i++)
-        {
-            if (i % 2 == 0)
-            {
-                sum += i;
-            }
-        }
-        Console.WriteLine(sum);
-    }
-}
-</code>
-Su equivalente declarativo sería:
-<code csharp>
-using System;
-using System.Linq;
-class Example
-{
-    static void Main()
-    {
-        Int32 sum = Enumerable.Range(0, 99)
-                      .Where(i => i % 2 == 0)
-                      .Sum();
-        Console.WriteLine(sum);
-    }
-}
-</code>
-O con un grado declarativo mayor:
-<code csharp>
-using System;
-using System.Linq;
-class Example
-{
-    static void Main()
-    {
-        Int32 sum = Enumerable.Range(0, 99)
-                      .Where(isEven)
-                      .Sum();
-        Console.WriteLine(sum);
-    }
-    static Boolean isEven(Int32 number)
-    {
-        return number % 2 == 0;
-    }
-}
-</code>
-===== Web Services =====
-==== REST Web Services ====
-La arquitectura REST (//Representational State Transfer//) es un estilo de distribución de datos mediante la web aprovechando el protocolo HTTP (métodos, URIs, Media Types, codigos de respuesta y petición...). Básicamente consiste en clientes que realizan peticiones a servidores, estos las procesan y retornan la respuesta adecuada. \\
-Tanto las peticiones como las respuestas intentan "representar recursos" (de ahí su nombre), entendiendo un recurso como "contenido" que puede ser accedido a partir de una dirección. \\
-En cualquier momento la aplicación cliente entrará en una transición de "estados de aplicación" (transición entre las distintas acciones que realiza una aplicación), se dice que si la aplicación entra en un estado "de descanso" (//at rest//) el usuario podrá interactuar con ella pero esta no cargará ni consumirá datos. La aplicación cliente enviará peticiones cuando esté preparada para una nueva transición. \\
-Un servicio REST asegura rendimiento, escalabilidad, simplicidad, modificabilidad, visibilidad portabilidad y confiabilidad.
-=== Servicios RESTful ===
-Las reglas a seguir en una arquitectura de estilo REST son las siguientes, si se siguen todas (excepto 'código //on demand//') el servicio podrá ser denominado RESTful:
-  - **Cliente - Servidor**: La interface de cliente está separada del servidor, esto significa que no pueden acceder directamente a los datos si no es a partir del mismo servidor. Por otra parte tanto el cliente como el servidor son independientes y han de ser desarrollados por separado.
-  - **Sin estados**: Las peticiones del cliente se harán de una en una y no por partes, cada una de estas contendrán toda la información necesaria para realizarla. Las peticiones se harán a partir de una URL.
-  - **Cacheable**: Los clientes han de ser capaz de guardar en caché las respuestas del servidor.
-  - **Sistema por capas**: Pueden existir servidores intermedios que mejoren la escalabilidad del sistema permitiendo el balanceo de carga y compartir cachés.
-  - **Código //on demand//** (opcional): El servidor puede ser capaz de transferir código al cliente (como por ejemplo JavaScript).
-  - **Interface uniforme**: Esto simplifica y desacopla la arquitectura, lo que permite a cada parte evolucionar independientemente. En una interface uniforme...
-    * Los recursos han de estar identificados en las peticiones. Esto significa que el servidor enviará los datos correctamente identificados en el formato que sea (HTML, XML, JSON...) y estos pueden ser una porción de la DB.
-    * Los recursos pueden ser manipulados. Esto significa que si el cliente tiene suficiente información del recurso y a la vez tiene suficientes permisos podrá realizar sobre este acciones de modificación, de borrado...
-    * Mensajes autodescriptivos. Cada mensaje ha de incluir suficiente información para que este pueda ser procesado.
-    * Los recursos han de ser reconocidos por métodos de hypermedia (como por ejemplo URIs).
-=== Formato ===
-De forma distinta a los web services basados en SOAP no existe un standard oficial (a parte de las reglas ya nombradas) para que un servicio sea RESTful, esto es porque REST es una arquitectura y SOAP un protocolo. Se definen tres aspectos para un servicio REST común:
-  * La URI base del web service, como por ejemplo: ''<nowiki>http://example.com/resources/</nowiki>''
-  * El tipo de dato devuelto (MIME type). JSON, XML, YAML...
-  * Las operaciones soportadas usando los método HTTP (por ejemplo PUT, GET, POST o DELETE).
-Ejemplo:
-^ URI ^ Método GET ^ Método PUT ^ Método POST ^ Método DELETE ^
-| http://example.com/resources/ | Lista todos los miembros. | Reemplaza la lista de miembros por otra. | Añade un miembro a la lista. | Elimina la colección. |
-| http://example.com/resources/142 | Recoge el elemento con id 142. | Actualiza el elemento con id 142. | | Elimina el elemento con id 142. |

Programming

Herramientas de usuario

Herramientas del sitio

Diferencias

Herramientas de la página