Entendiendo RESTful Web services

Index

RESTful Web Services

Conceptos basicos acerca del funcionamiento de WS RESTful...

1. RESTful web services

1.1. Introduccion

1.2. Discoverability e Hypertext Application Language (HAL)

2. Enlaces de interes

Tech target

1. RESTful Web services

1.1. Introduccion

Representational State Transfer (REST), es un concepto de web service que se parece en muchos aspectos a SOAP. La arquitectura REST esta formada por varios servidores y clientes. Los clientes realizan transiciones entre estados mediante acciones (peticiones a servidor para obtener o realizar un cambio de estado en los recursos), el servidor por su lado procesa las peticiones y devuelve los recursos. Un recurso puede ser cualquier concepto logico que es comprendido por ambos, cliente y y servidor, y que se transmite de forma acordada bajo una representacion. REST no depende o indica explicitamente un tipo de recurso o representacion. Dichos recursos pueden ser de cualquier tipo de dato que podamos establecer. Sus representaciones pueden ser por ejemplo, texto plano, HTML, XML, YAML, JSON, datos binarios, o cualquier otro tipo de formato que se entienda por el cliente y el servidor. Un sistema REST trabaja mediante URLs las cuales indican el tipo de recurso del que se trata, e instrucciones (veremos con el mapeo al protocolo HTTP, tales como GET, POST...), que indican la accion que se ha de realizar sobre el recurso, ademas del tipo de medio que representa el recurso (indicado por el MIME type), a tratar en las request y response. Es normal que nos recuerde a la forma de comunicacion de la WWW y el protocolo HTTP. Ademas de creador de parte del protocolo HTTP 1.0 y 1.1 Roy Fielding habla de “Representational State Transfer” en su tesis doctoral de 2000. World Wide Web es, por naturaleza, el gran sistema REST.

Uno de los principios fundamentales de los servicios RESTful es que se basa en un numero reducido de operaciones, que han de ser realizadas sobre un recurso. En este caso, el conjunto de operaciones se conoce como CreateReadUpdateDelete. Estos metodos se asignan a operaciones del protocolo HTTP facilmente sobre las acciones POST, GET, PUT y DELETE , respectivamente, mientras que SOAP utiliza el elemento envelope para indicar que tipo de accion realizar (el metodo que ha de ser invocado), REST basa las operaciones dentro del protocolo HTTP. En SOAP, el envelope, contiene ademas la referencia al recurso sobre el que se actua, mientras que REST dicha referencia va implicita en la URL.

En un servicio RESTful, la cabecera de peticion “Content-Type” indica al servidor acerca del la representacion del cuerpo de dicha peticion; la cabecera “Accept” o la extension de fichero en la URL, solicita el recurso de un tipo concreto, la cabecera de la respuesta “Content-Type”, informa al cliente la representacion del cuerpo de la respuesta.

Veamos algunas ventajas y desventajas que ofrece cada uno de los protocolos. La primera, un ws RESTful esta ligado a HTTP, miestras que SOAP es independiente del protocolo, lo que da ventaja a SOAP. Aunque no seria imposible crear un ws RESTful que fuese independiente, esto añadiria complejidad y dejaria de cumplir el concepto de REST. Ya que REST maneja: URLs, acciones y tipos de medio, al igual que lo hace HTTP lo que sirve como envelope para las request, response. Es posible con un mapeo directo a HTTP utilizar distintos tipos de dato, mientras que SOAP necesita que se pase a XML. SOAP es un protocolo redundante ya que se trata de un envelope contenido dentro de otro. Esta duplicidad del elemento envelope a la vez permite que sea independiente del protocolo HTTP y duplica la funcionalidad que ofrece directamente la referenciacion del recurso por URL y las acciones con metodos HTTP.

Una desventaja de los web services RESTful es que carecen de un tipado definido, como el que tiene SOAP a traves de los esquemas WSDL. Esto hace que no exista un contrato propio predefinido entre la peticion y la respuesta sino lo que se llama “contract-last”. Esto no impide que se pueda establecer dicho contrato, pero esta basado en una documentacion, haciendolo disponible mediante un API publica, en contraposicion a complejos esquemas XSD. Sin embargo algunos proveedores de ws RESTful llegan incluso a publicar dicha especificacion mediante un esquema XSD o en formato JSON.

plificar la funcionalidad aún siendo dependiente del protocolo HTTP, la aquitecutra RESTful se esta imponiendo a la hora de implementar Web Services y se integra ya en varios frameworks tales como Spring MVC.

1.2. Discoverability e Hypertext Application Language (HAL)

Una caracteristica importante de los ws RESTful es su “discoverability”. Mediante una combinacion de URL y metodos HTTP como OPTIONS, los clientes pueden descubrir los recursos disponibles que ofrece el web service, sin tener que establecer un contrato previo. De esta manera los clientes pueden saber las acciones que se pueden realizar sobre cada recurso. Aunque muchos proveedores de ws RESTful no ofrecen dicha posibilidad, es una ventaja central de la arquitectura REST. En WWW todo es posible de identificar mediante su URL, como usuario, es posible desde el navegador acceder a cualquier recurso publico y siguiendo la cadena de enlaces llegar al resto.

Esta restriccion se encuentra tambien dentro de las especificaciones REST. De manera que sea posible acceder a un recurso a partir de otro. Este concepto se conoce como “Hypermedia as the Engine of Application State” (HATEOAS), para ello se usa XML, YAML, JSON, o cualquier otro formato junto con hiperenlaces para informar al cliente acerca de la estructura del ws. Por ejemplo, una request-response hacia un web service podria ser de la siguiente manera.

/*peticion*/
GET /servicios/rest/ HTTP/1.1
Accept: application/json

200 OK

Content-Type: application/hal+json

{

"_directorio": {

"self": { "href": "http://site.net/servicios/rest" },

"cuenta": { "href": "http://site.net/servicios/rest/cuenta" },

"pedido": { "href": "http://site.net/servicios/rest/order" }

}

}

Asi el cliente conoce los recursos disponibles en el web service. Si desea acceder al servicio de “cuenta” mas adelante, puede realizarlo o bien mediante una peticion GET al un recurso especifico llamado una “collection request” o bien una peticion a una URI, que devuelve todos los recursos de ese tipo disponibles.

GET /services/Rest/account HTTP/1.1

Accept: application/json


200 OK

Content-Type: application/json

{

"value": [

{

"id": 1075,

"name": "Joe Doe",

...

}, {

"id": 1076,

"name": "Alice Green",

...

}

]

}

Esto presenta la desventaja de que la respuesta con la coleccion puede ser muy grande (enorme incluso). La solucion seria aplicar paginacion en la respuesta. Otro problema, es que se muestran los recursos propiamente, no su ubicacion (mediante una URL por ejemplo). Para esto una forma seria devolver una lista de enlaces, pero esto lo hace inviable a la hora de utilizar estos datos por la parte cliente. Por esta razon, muchos web services usan una combinacion de atributos y un enlace al recurso.

Otra accion que puede realizar el cliente es solicitar los recursos disponibles dentro del un recurso devuelto mediante la peticion OPTIONS a dicho recurso.

OPTIONS /servicios/rest/cuenta HTTP/1.1

Accept: application/json
/*respuesta*/

200 OK

Allow: OPTIONS,HEAD,GET,POST,PUT,PATCH,DELETE

{

"GET": {

"description": "Recursos disponibles dentro de cuentas",

"templateAcceso": "http://site.net/servicios/rest/cuenta/{id}",

"parametros": {

"$select": {

"type": "array/string",

"description": "Propiedades de cada recurso disponible.",

},

"$filter" ...

}

},

"POST" ...

}

La respuesta OPTIONS puede ser muy util ya que no solamente indica al cliente cuales son las acciones que puede realizar sobre el recurso, sino que puede ademas filtrarse de acuerdo con los “permisos” que dicho cliente tenga. Por ejemplo, si el cliente puede Read pero no Create, Update o Delete, la response devolveria la cabecera “Allow: OPTIONS,HEAD,GET “. Junto con las acciones que fuesen posibles para los distintos recursos y sus parametros como vemos en la siguiente peticion y sus respuestas:

OPTIONS /services/rest/cuenta/1075 HTTP/1.1

Accept: application/json

200 OK

Allow: OPTIONS,HEAD,GET,PUT,PATCH,DELETE

….

OPTIONS /services/rest/cuenta/1076 HTTP/1.1

Accept: application/json

200 OK

Allow: OPTIONS,HEAD,GET

 ...

El primer problema para descubrir los servicios web RESTful es que no existe un acuerdo previo establecido entre cliente y servidor acerca del formato de las reponses de tipo “discovery” (OPTIONS).

En los ejemplos hemos visto el uso de una representacion JSON de Hypertext Application Language (HAL), lo que es, uno de los standares emergentes pero no es el unico. En cuanto al contenido del cuerpo de la respuesta, no hay un protocolo, a menudo depende de la implementacion del API.

2. Enlaces de interes

Algunos enlaces:

REST Wikipedia

Building RESTful Web Service

Techtarget

Introduccion a Groovy

Index

Introduccion a Groovy

Conceptos basicos del lenguaje Groovy...

1. En Java...en Groovy

2. Instalando Groovy

3. Tipos de dato

4. Closures

5. Enlaces de interes

Groovy core semantics

1. En Java...en Groovy

Ejemplo basico en Java :

public class HelloEcho {
   public static void main( String[] args )
      System.out.println("Hello Echo!");
   }
}

Se ejecutaria tambien en Groovy !!

Veamos otras caracteristicas del lenguaje :

1) Es debilmente tipado, como JavaScript o Perl. 2) El ambito de metodos y atributos de clase es por defecto public. 3) Punto y coma al final de linea es opcional

asi, la sintaxis siguiente seria correcta:

class HelloEcho {
   static main( args ){
 def avar = « Echo ! »
 println "Hello ${ avar }"
   }
}

Ademas, como dijimos Groovy es un lenguaje dinamico, lo que no impide que sea un lenguaje interpretado. De heco, cada clase Groovy se compila como una clase Java (lo que lo distingue de otros lenguajes de la JVM), aun cuando escribimos y ejecutamos el codigo desde scripts (no clases formales), se compilara como clase Java.

//se compila en Java bytecode
println "Hello World!"
Otra forma, en Groovy, usando  clases :
class HelloEcho {
   def greet( snds ){
      "Hello ${snds}!"
   }
}

def earv = new HelloEcho()
println earv.greet("Echo !")

En el ejemplo vemos 3 caracteristicas del lenguaje:

1) El tipo de retorno del metodo "greet"" no es de un tipo concreto, asi que usamos el keyword def (semejante a var en JS). 2) Si no indicamos « return » el valor de retorno sera el devuelto por la ultima sentencia ejecutada. 3) La cadena « Echo ! » no es de tipo java.lang.String, esto es una de las caracteristicas mas interesantes, es de tipo « GString ». Este tipo de strings nos permiten evaluar variables en su interior asi como expresiones, similar a como hace el lenguaje Perl.

2. Instalando Groovy

Para la instalar Groovy y lanzar los ejemplos desde la consola :

1) Descargar la ultima version desde http://groovy.codehaus.org/Download

2) En Windows existe el instalador NSIS-Installer, para versiones en Ingles, Español, Aleman y Frances.

3) Instalacion manual : Descomprime el paquete en un directorio, con permisos suficientes, por ejemplo C:\groovy en Windows, /usr/local/groovy en Linux.

4) Crear la variable de entorno GROOVY_HOME que apunte hacia ese directorio.

5) Debes tener instalado Java (JRE 1.4 o superior), y declarada la variable JAVA_HOME.

6) Añadir al PATH : GROOVY_HOME/bin

Ya puedes ejecutar scripts *.groovy ! Puede hacerlo de 3 formas :

1) La mas sencilla es a partir de ejecutar el interprete (es un lenguaje script, recuerda!). Asi el ejemplo anterior se ejecutaria desde la linea de comandos :

// hello-echo.groovy tiene permisos de ejecucion
$>groovy hello-echo.groovy

2) Lanzar el propio shell de groovy : groovysh

3) Lanzar la consola basada en Java Swing de Groovy , esta es la opcion mas recomendada para principiantes (no olvides configurar en las opciones, los jar necesarios para el classpath).

3. Tipos de dato

Una vez instalado Groovy (ya veremos como añadirlo a IDEs como Eclipse, mediante sus Plug-in), empezaremos a explorar el lenguaje. Empezando por los tipo de dato que soporta. Al contrario de Java, en el que existen tipos basicos, en Groovy todo es objeto (Smalltalk). Ademas, a la hora de ejecutar una sentencia, por ejemplo un bucle, existen multiples formas de hacerlo. Por ejemplo :

//escribe hola 3 veces
3.times {
   println "hola"
}
(1..3).each {
   println "hola"
}

El codigo print »Hola » se encuentra dentro de lo que se define como Closure, es importante este concepto de bloques de codigo. En Groovy se aceptan todos los tipos de tato Java (para ello se llama a los wrappers -Integer, Double,Boolean…-, en lugar de los tipos basicos). Para las collections como maps y list, se tratan de forma parecida a PHP o Perl. Las listas son en realidad instancias de  java.util.ArrayList  y los maps de java.util.HashMap, por lo que disponemos de sus metodos, sin embargo Groovy añade la posibilidad de acceder a los indices con el operador '[]' y en el caso de maps con la notacion punto.

//List y Maps en Groovy
def lista = [9,1,2,8,3,0,4,5,7,8, 2,4, 0, 0, 1]
def map = ["clave":"valor"]

//
assert list.get(0) == 9
assert list[0] == 9
assert map.get("clave") == "valor"
assert map["clave"] == "valor"
assert map.clave == "valor"
assert map."clave" == "valor

def listVacia = []
def mapVacio = [:]

// En listas no necesario el operador .add() 
def lista = []
lista[9] = 10
assert lista[9] == 10
assert lista.size() == 10 
//iterar lista.each{ item →...}

El uso de rangos define una secuencia de valores que puede iterarse en ambos sentidos. Se usan a menudo para crear listas dentro de una lista, pero puede usarse en mas casos.

// operador rango [] en un string es semejente a substring() o charAt() on the string
println "Soyunstring"[0..7]
// salida : Soyunstr

//bucle indicado por un rango
(0..10).each { num -> print num }
// prints 012345678910
('a'..'d').each { letra -> print letra }
// prints abcd

En Groovy existen ademas otros metodos que se añaden a las colecciones. Estos vienen con el GDK. Para muchos de estos metodos, se usan las Closures del lenguaje.

4. Closures

Veamos algunos ejemplos de closures, podemos comprenderlo como bloques de codigo reutilizables.

//Scope
def nombre = "Abracadabra"
def conjuro = {
   println nombre
}
conjuro()
// escribe « Abracadabra »

Las closures son similares a « funciones anonimas » dentro de un script. Podemos pasar parametros, el tipo y el nombre, pero al tratarse de un lenguaje dinamico, el tipo se puede obviar:

def escribe = { elem -> print elem }
(0..9).each escribe
('a'..'f').each escribe
//0123456789abcdef

Existen parametros por defecto para las Closures, incluso si no lo declaramos, disponemos de, « it »

def escribe = { print it }
(0..9).each escribe
('a'..'f').each escribe
//  0123456789abcdef

// Otras formas de iterar
//1
[0,1,2,3,4,5,6,7,8,9].each escribe
//2
(0..9).each escribe
//3
10.times escribe
//4
0.upto 9, escribe
//5 
def lista =[0,1,2,3,4,5,6,7,8,9] 
for( num in lista) escribe.call(num)

En el caso del bucle « for », hay que usar una llamada a « call » dentro de « escribe ». Esto se debe a que for no puede acceder al cuerpo de la closure de « escribe », sino que debe ser un bloque semejante a Java. (ver la declaracion de « escribe »)

5. Enlaces de interes

Algunos enlaces:

Making Java Groovy

Closures

Differences with Java

Groovy core semantics