Arquitectura RESTFul

Estas son las notas del primer capitulo del libro Hands-On RESTful API Design Patterns and Best Practices que recomiendo encarecidamente adquirir, ya que aclara los conceptos que aquí apenas se mencionan. Lo siguiente es un resumen que está lejos de tener el valor de todos los matices que abarca el libro.

Algunos conceptos o definiciones previos:

XML/JSON (Extensible Markup Language/ JavaScript Object Notation) es el formato que provee metadata para los datos que son contenidos dentro de los mensajes que intercambian los sistemas/servicios

SOAP (Simple Object Accces Protocol): usado para para transferir datos.

WSDL (Web Services Description Language) : se usa para definir los servicios disponibles que pueden ser consumidos

UDDI (Universal Description, Discovery, and Integration) es una lista de los servicios disponibles.

URI (Uniform Resource Identifier) se usa para identificar la ubicación de recursos en una red.

API (Application Programming Interface) especifica como un componente de software se comunica con otros componentes.

REST (Representational State Transfer) es una manera o estilo de exponer funciones y datos para ser consumidos en un ambiente distribuido.

SOA (Service Oriented Architecture): define estándares y enfoques para el diseño de web services y cómo estos se comunican entre sí. Aquí, un web service es la representación lógica actividades de negocio repetibles,  son una operación que tienen un resultado específico: obtener el costo de un producto, actualizar el inventario, obtener la ubicación de un negocio. Para el consumidor el webservice que consume es una caja negra. Estas alojados en servidores e interactúan con otras aplicaciones a través de interfaces.

ROA (Resourse Oriented Architecture): es una arquitectura fundada en la semántica de la web. Define un diseño estructural y guías para soportar e implementar interacciones con cualquier recurso conectado. En este contexto, cualquier entidad de negocio puede ser representado por como un recurso y pude ser accesible a través de una URI. Así en un sistema de recursos humanos cada empleado es una entidad (servicio) y sus detalles, salario, perfil, son asociaciones (descriptores) de una entidad y cada entidad puede permitir varias acciones (contratos).

Como se apuntó ROA está fundamentada en la semántica de la web ¿Cuál semántica? Las operaciones o “verbos” que implementa el protocolo HTTP , es decir:

VERBO	USO
GET	Leer las representaciones de un recurso
PUT	Creación de un nuevo recurso.
DELETE	Eliminación del recurso (y de los recursos ligados, de forma opcional)
POST	Modificación del recurso.
HEAD	Meta información del recurso.

Ahora, para decir con propiedad que tenemos una API que es REST ésta debe cumplir con ciertas restricciones  y propiedades (dadas por Roy Fielding, quien propuso en primera instancia el concepto de REST) Entre las propiedades están: se exponen recursos, no se mantiene estado entre requests, direccionabilidad (el recurso debe usar una dirección), uniformidad y usar el protocolo HTTP para la comunicación de los datos.

Entre las restricciones (Constraints) REST están:

• Cliente-Servidor: La comunicación se da entre el cliente (o muchos clientes) que es quien quién solicita un servicio, utilizándolos mediante el envio de requests, y el servidor que es quien provee el servicio a consumir, manejando los request o solicitudes para acceder a los mismos. Clientes y servidor típicamente existen en un ambiente distribuido comunicándose a través de una red por medio de patrón request-respond.

• Statelessness (sin estado): Significa que el servidor no mantiene ninguna información o estado contextual entre los requests. Dicho de otra forma cada llamado (request) del cliente debe contener toda la información necesaria de manera explícita para que el servidor pueda entenderlo y manejarlo de manera totalmente independiente. Esto asegura escalabilidad y confiabilidad del lado del servidor. Es importante señalar que es el cliente, entonces, quien debe mantener algún mecanismo para mantener contexto entre las llamadas al servidor.

• Caching (Caché): en el contexto de REST se refiere a la posibilidad almacenar datos de uso frecuente de manera que parcial o totalmente se elimine la necesidad de la comunicación entre el cliente y el servidor, disminuyendo la latencia y mejorando el rendimiento en el lado del cliente. Hay diversas estrategias para el caching: browser caché, proxy caché, gateway cache (reverse proxy). Usualmente se usan algunos tags a nivel de headers para controlar el cache: expires, Cache-control,E-Tag, Last-Modified. (más información).
• Interfaz Uniforme: como se mencionó anteriormente se refiere a la combinación de la semántica del HTTP, con el concepto de recurso, creando una interfaz uniforme. Es decir donde GET, es siempre leer, y DELETE es siempre eliminar con respecto a un recurso cualquiera este sea. Esto es parte del corazón de REST, Roy Fielding, instituyó cuatro principios necesarios para alcanzar a cabalidad la restricción de interfaz uniforme:

1. Identificación de los recursos: cada recurso debe estar identificado inequívocamente  por medio de un URI. Así el URI para ubicar un empleado será https://api.MyRRHH.com/1.1/Planilla/Empleados/:id.json los datos devueltos podrán refinarse y mejorase con la evolución de las versiones pero está siempre será la forma de acceder al recurso empleado.
2. Manipulación del recurso: se refiere a la independencia del URI de un recurso y los formatos en la que la información es devuelta al cliente. Puede que la misma URI exponga el recurso solicitado en diferentes formatos: JSON, XML, HTML,  PNG, SVG, etc (Multipurpose Internet Mail Extension (MIME))  permitiendo que el cliente manipule esta data según sus posibilidades y conveniencia. Para lograr esto el servidor habilita a través del tag Accept del Http header que el cliente le solicite el formato en que requiere el recurso. Separar la representación (formato) del recurso  de la URI del mismo es un aspecto crucial de REST.
3. Mensajes Auto-Descriptivos: REST descansa sobre el principio de que tanto el request del cliente como el response del servidor son estandarizados (tienen cuerpo y metadata) y son autodescriptitvos es decir usan los tipos de mensajes: GET, HEAD, OPTIONS, PUT, POST y DELETE) de manera que son completamente comprendidos tanto por el servidor como por el cliente. De esta manera se tiene el mecanismo por medio del cual los mensajes contienen la información necesaria, manteniéndose cada uno independiente, sin necesidad de mantener estados en el servidor.
4. Hypermedia como el motor de Estado de Aplicación (Hypermedia as the Engine of Application State (HATEOAS)): Sin esta característica no podemos argumentar que un servicio es RESTful, fue introducida en el modelo Richardson Maturity Model (RMM) por Leonard Richardson. Se trata del siguiente paso una vez tenemos un servicio que expone un recurso a través de un URI accesible a por medio de los verbos de HTTP, y consiste en brindar al cliente que consume un recurso la guía de qué es lo siguiente que puede hacer con él. Esto se realiza por medio de un dato más denominado de forma estándar “link” o “links” que acompaña la respuesta del servidor. Para ponerlo menos abstracto imaginemos un servicio que nos devuelve una lista de las citas disponibles de un doctor, con HATEOAS a cada uno de los  ítems devueltos se le añade un dato link que nos indica cual es el URI para tomar esa particular cita de manera que el cliente es guiado al siguiente paso o estado de la aplicación. Resumiendo, HATEOAS se refiere a que la representación de un recurso devuelta por un servicio incluye links que le indican a quien lo consume recursos relacionados con el mismo.

• Sistemas en capas: consiste en sistemas que se componen de unidades que se comunican a través de interfaces predefinidas desempeñando diversas funciones. Estas capas puede estar físicamente separadas de manera que, por ejemplo, la API REST se instala en el servidor A, la autenticación se realiza en el servidor B y los datos se almacenan el servidor C. REST sugiere que los servicios pueden estar constituidos por múltiples capas, que éstas publican contratos de servicios y que, en un ordenamiento jerárquico, la lógica de una capa dada únicamente puede ser conocida por la capa inmediatamente superior o  inmediatamente inferior.

Resumiendo:
El mismo Roy Fielding, fundador del estilo REST, dejó claro que para que un API (servicio) se atribuya el estatus de RESTful debe cumplir con las restricciones de su estilo de arquitectura, es decir cumplir con:

• Cliente-Servidor
• Statelessness
• Caching
• Interfaz Uniforme
• Sistema en capas.

Las metas de una arquitectura REST son cumplir con las siguientes propiedades:

• Rendimiento
• Escalabilidad
• Simplicidad
• Modificabilidad
• Visibilidad
• Portabilidad
• Confiabilidad
• Testeability (susceptible de probarse)

Una  vez mas sugerir la adquisición del libro Hands-On RESTful API Design Patterns and Best Practice para aclarar los conceptos que quedan oscuros en este resumen.

Leer más

El secreto de la felicidad…

Ya tengo mis años en estas andanzas, me quedan dos años para alcanzar mi 40va primavera (aunque también he tenido inviernos), son casi 17 años de vida profesional, y desde que comencé este camino he tenido claro una cosa que, muy honestamente y sin tratar de engañarme a mismo (más de una vez me he sorprendido tratando de engañarme), ha logrado mantenerme feliz: Hago lo que me gusta hacer, simple y llanamente.

Desde muy temprana edad, en la época de chiquillo de escuela, conocí las computadoras. Aquellos cajones con letras en verde chillón o ámbar en fondo negro, me cautivaron, me enamoraron desde el principio. Unos cursos gratuitos de Logo y Logowriter que vinieron a ofrecer del Liceo León Cortés Castro (Grecia, Alajuela, Costa Rica) a mi escuela rural de distrito, fueron el disparo de salida para sumergirme en lo que iba a ser el resto de mi vida…

Había que ir y venir en autobús, en tiempo fuera de horario escolar. Para un niño sumamente tímido y retraído aquello era todo un reto, casi una hazaña;  pero ver moverse aquella tortuguita digital formando figuras a partir de los comandos que yo creaba, bien valían la pena: aquello me hacia feliz.

Computadora no había en casa, con mucho costo había un televisor a blanco y negro y un atún para repartir entre cinco más algo de arroz y frijoles. En esa época era impensable contar con una. Pero yo sabía que, tarde o temprano, me iba a dedicar a trabajar con computadoras sí o sí.

Un amigo, de más musculo económico, adquirió una. Aquella era una maravilla, no solo tenía verde, sino hasta 8 colores ¡8 colores! No existía nada en el mundo mejor que jugar Test Drive. Pasaba cada vez que podía, y, aunque los turnos para usarla eran largos, yo era feliz.

Llegué al colegio, al mismo liceo de los cursos, y salvo un brevísimo periodo de coqueteo con la biología (en parte por culpa de una joven y bonita profesora sustituta) mi ruta era clara, estar cerca del laboratorio de informática y llevar computación como materia técnica. Me gustaba mucho aprender, no únicamente de computadoras, y mientras aprendía era feliz.

Llegué a la universidad decido a estudiar informática, aunque no tuviera “machete” o herramienta. Pero mi padre y madre, quiénes con mucho esfuerzo habían logrado hacerse de un lotecito, lo sacrificaron para comprarme mi primer computadora. Jamás nunca podré pagarles ni agradecerles lo suficiente.

Aún recuerdo las palabras de recibimiento de la directora de la carrera, quien, además, impartía el curso de lógica: “Aquí no vienen a aprender a digitar, ni a usar paquetes ofimáticos, aquí van a aprender a programar una computadora”. Éxtasis…

Todos los cursos de programación los pasé con muy buenas notas, mas no todo fue fácil, muy a mi pesar también repetí un par de cursos. Pero no importaba, estar ahí y saber cómo funciona un programa, como decirle a una computadora que hacer en PASCAL o en FOX-DOS, era simplemente demasiado bueno para ser cierto. Era muy feliz.

Al final de la carrera universitaria las oscuras garras de la duda intentaron sujetar mi voluntad. ¿Y si no consigo trabajo? ¿Y si no es cómo lo imagino? ¿Y si no cumplo las expectativas? ¿Y si no gano lo suficiente? Y muchas otras preguntas asaltaban mi cabeza; algunas eran dudas razonables otras eran estúpidos miedos queriendo convertirse en excusas para tomar pésimas decisiones.

Al final, posterior a una práctica empresarial que me dejó un mal sabor, aunque fue experiencia al fin y al cabo, y luego de una única entrevista de trabajo, en Julio de 2001 llegué a mi segunda casa, a mi segundo hogar. ¡Y nada era como lo imaginaba! Todo es más difícil, mucho más complicado pero también excepcionalmente gratificante.

Desde entonces he programado casi siempre, algunas veces con más otras con menos responsabilidades, con muchos colegas al mismo tiempo o autogestionándome completamente solo y, aunque también se hacen muchas otras tareas de la forma más profesional posible como reuniones con clientes, levantamiento de requisitos, diseño, documentación, manuales, ayuda, aspectos gráficos, presentaciones de productos, capacitaciones, etc… para mí lo importante es que tarde o temprano termino programando y eso me hace simplemente feliz.

Aunque he tenido y sé que habrá días en que hubiera sido mejor no salir de la cama (porque para todos existen esos días complicados) y que habrá problemas grandes y pequeños que solucionar y situaciones difíciles que enfrentar, laborales y personales. El secreto para ser feliz la mayor parte de mi existencia ha consistido y consiste aún, en haber encontrado lo que realmente me apasiona (afortunadamente muy temprano) y haber tomado la decisión de dedicarme a eso como forma de vida. Hacer lo que me gusta, dedicarme a lo que realmente me gusta es mi secreto para ser feliz.

Leer más

Scripts útiles: Ranking de Tablas y Búsqueda en Procedimientos Almacenados

 Algunas veces necesitamos algunos pequeños scritps de SQL para hacernos la vida más simple. A continuación dejo dos de éstos.

El primero lista las tablas en una base de datos en orden cantidad de registros en ellas en orden decendente.

SELECT  O.name TABLA, I.rows AS REGISTROS
FROM sysobjects O
	INNER JOIN sysindexes I ON I.id = O.id 
WHERE O.xtype= 'U'
	AND I.indid IN (0, 1)
ORDER BY REGISTROS DESC;

es útil para encontrar tablas candidatas a particionamiento .

El segundo sirve para buscar texto en los procedimientos almancenados o funciones

DECLARE @buscar nvarchar(max)='texto a buscar' 

SELECT OBJECT_NAME(id)
FROM sys.syscomments
WHERE [text] LIKE '%'+ @buscar +'%'
AND (
	OBJECTPROPERTY(id, 'IsProcedure') = 1
	OR OBJECTPROPERTY(id, 'IsInlineFunction') = 1
	OR OBJECTPROPERTY(id, 'IsScalarFunction') = 1
	OR  OBJECTPROPERTY(id, 'IsTableFunction') = 1
	)
GROUP BY OBJECT_NAME(id)

Muy útil cunado queremos buscar codigos de registros, parametros etc

Leer más