Libros gratuitos

 

Download FREE IT Guides!   Linux Bible, 10th Edition ($36.00 Value) FREE for a Limited Time Linux Bible, 10th Edition is the ultimate hands-on Linux user guide, whether you're a true beginner or a more advanced user navigating recent changes. this updated tenth edition covers the latest versions of Red Hat Enterprise Linux     Teach Yourself VISUALLY Windows 11 ($19.00 Value) FREE for a Limited Time Teach Yourself VISUALLY Windows 11 collects all the resources you need to master the day-to-day use of Microsoft’s new operating system and delivers them in a single resource. Fully illustrated, step-by-step     RESTful Architecture Cheatsheet The web has become an integral part of our daily lives, and with it, web applications have also become increasingly popular. However, as the number of web applications has grown, so has the complexity of managing them     Modern API Development with Spring and Spring Boot ($33.99 Value) FREE for a Limited Time Developers need to know how to adapt to these modern API design principles. Apps are now developed with APIs that enable ease of integration for the cloud environment and distributed systems.

Creando un web service REST con ZIO

 Vamos hacer un pequeño proyecto con ZIO, como para empezar. El "hola mundo" de toda la vida pero en un servicio REST. 

Antes de empezar vamos a hacer un proyecto con scala 3 con sbt : 

sbt new scala/scala3.g8

Luego agregamos las dependencias de zio, el build.sbt debe quedar así : 

scalaVersion := "3.1.2"

organization := "dev.zio"

name         := "zio-quickstart-restful-webservice"

libraryDependencies ++= Seq(

  "dev.zio"       %% "zio"            % "2.0.0",

  "dev.zio"       %% "zio-json"       % "0.3.0-RC10",

  "io.d11"        %% "zhttp"        % "2.0.0-RC10",

  "io.getquill"   %% "quill-zio"    % "4.2.0",

  "io.getquill"   %% "quill-jdbc-zio" % "4.2.0",

  "com.h2database" % "h2"             % "2.1.214"

)

Aclaro que tengo otras dependencias como la de base de dato que las voy a usar en proximos ejemplos. 

Y ahore si, hacemos el web service para nuestro "hola mundo" : 

package dev.zio.quickstart.greet

import zhttp.http._

object GreetingApp {

  def apply(): Http[Any, Nothing, Request, Response] =

    Http.collect[Request] {

      // GET /greet?name=:name

      case req@(Method.GET -> !! / "greet") if (req.url.queryParams.nonEmpty) =>

        Response.text(s"Hello ${req.url.queryParams("name").mkString(" and ")}!")

      // GET /greet

      case Method.GET -> !! / "greet" =>

        Response.text(s"Hello World!")

      // GET /greet/:name

      case Method.GET -> !! / "greet" / name =>

        Response.text(s"Hello $name!")

    }

}

Luego programamos el Main :

package dev.zio.quickstart

import dev.zio.quickstart.counter.CounterApp

import dev.zio.quickstart.download.DownloadApp

import dev.zio.quickstart.greet.GreetingApp

import dev.zio.quickstart.users.{InmemoryUserRepo, PersistentUserRepo, UserApp}

import zhttp.service.Server

import zio._

object MainApp extends ZIOAppDefault {

  def run =

    Server.start(

      port = 8999,

      http = GreetingApp() 

    ).provide(

      // An layer responsible for storing the state of the `counterApp`

      ZLayer.fromZIO(Ref.make(0)),

      

      // To use the persistence layer, provide the `PersistentUserRepo.layer` layer instead

      InmemoryUserRepo.layer

    )

}

Y listo!! Si vamos a http://localhost:8999/greet?name=Emanuel me va a saludar. 

Para correrlo lo pueden hacer con sbt run o con intellij corriendo el Main. 

Dejo el repo : 

https://github.com/emanuelpeg/zio-quickstart-restful-webservice

El patrón de arquitectura microservicios

El patrón de arquitectura microservicios está ganando rápidamente terreno en la industria como una alternativa viable a las aplicaciones monolíticas y arquitecturas orientadas al servicio. Debido a que este patrón de arquitectura sigue evolucionando, hay mucha confusión en la industria acerca de lo que es este patrón y cómo se implementa. 

Independientemente de la topología o el estilo de implementación elegidos, hay varios conceptos básicos comunes que se aplican al patrón de arquitectura general. El primero de estos conceptos es la noción de unidades desplegadas separadamente. Cada componente de la arquitectura de microservicios se despliega como una unidad separada, permitiendo un despliegue más fácil a través de una tubería de entrega efectiva y simplificada, mayor escalabilidad y un alto grado de aplicación y desacoplamiento de componentes dentro de su aplicación.

Quizás el concepto más importante para entender con este patrón es la noción de un componente de servicio. En lugar de pensar en los servicios dentro de una arquitectura de microservicios, es mejor pensar en los componentes del servicio, que pueden variar en granularidad de un solo módulo a una gran parte de la aplicación. Los componentes de servicio contienen uno o más módulos (por ejemplo, clases de Java) que representan una función de un solo propósito (por ejemplo, proporcionar el tiempo para una ciudad o ciudad específica) o una parte independiente de una aplicación empresarial grande. Diseñar el nivel adecuado de granularidad del componente de servicio es uno de los mayores desafíos dentro de una arquitectura de microservicios.

Otro concepto clave dentro del patrón de arquitectura de microservicios es que es una arquitectura distribuida, lo que significa que todos los componentes dentro de la arquitectura están completamente desacoplados entre sí y se accede a través de algún tipo de protocolo de acceso remoto (por ejemplo, JMS, AMQP, REST, SOAP, RMI, etc.). La naturaleza distribuida de este patrón de arquitectura es cómo consigue algunas de sus características de escalabilidad y despliegue superiores.

Existen docenas de implementaciones de este patrón arquitectonico, pero las más comunes son: basado en un API REST, basado en una aplicación REST y de mensajería centralizada.

La topología de API REST es útil para los sitios web que desean exponer servicios atravez de una API. Un ejemplo de estos son las APIs que proveen servicios de Google, Yahoo o/y Amazon.

La topologia basada en REST es un tanto diferente a la anterior dado que las solicitudes del cliente se reciben a través de pantallas de aplicaciones empresariales tradicionales basadas en web o en clientes en lugar de a través de una simple capa API. La capa de interfaz de usuario de la aplicación se despliega como una aplicación web separada que accede de forma remota a componentes de servicio desplegados por separado (funcionalidad empresarial) a través de simples interfaces basadas en REST. Los componentes de servicio en esta topología difieren de los de la topología basada en API-REST en que estos componentes de servicio tienden a ser más grandes, de grano más grueso y representan una pequeña porción de la aplicación empresarial general. Esta topología es común para las aplicaciones empresariales pequeñas y medianas que tienen un grado relativamente bajo de complejidad.

Otro enfoque común dentro del patrón de arquitectura de microservicios es la topología de mensajería centralizada. Esta topología es similar a la topología anterior basada en REST, excepto que en lugar de usar REST para acceso remoto, esta topología utiliza un intermediario de mensajes centralizado ligero (por ejemplo, ActiveMQ, HornetQ, etc.). Es de vital importancia al considerar esta topología no confundirlo con el patrón de arquitectura orientada al servicio o considerarlo "SOA-Lite". El agente de mensajes ligeros que se encuentra en esta topología no realiza ninguna orquestación, transformación o enrutamiento complejo. Es sólo un transporte ligero para acceder a los componentes de servicio remotos.

La topología de mensajería centralizada se encuentra típicamente en aplicaciones de negocios más grandes o aplicaciones que requieren un control más sofisticado sobre la capa de transporte entre la interfaz de usuario y los componentes de servicio. Los beneficios de esta topología sobre la simple topología basada en REST discutida anteriormente son mecanismos avanzados de colas, mensajería asíncrona, monitoreo, manejo de errores y mejor balanceo de carga y escalabilidad. El único punto de fallo y los problemas de cuello de botella arquitectónico generalmente asociados con un intermediario centralizado se abordan a través de la agrupación de intermediarios y de la federación de intermediarios (dividir una única instancia de intermediario en múltiples instancias de intermediario para dividir la carga de procesamiento de mensajes en función de las áreas funcionales del sistema).

El patrón de arquitectura de microservicios resuelve muchos de los problemas comunes encontrados tanto en aplicaciones monolíticas como en arquitecturas orientadas a servicios. Dado que los principales componentes de la aplicación se dividen en unidades más pequeñas, desplegadas por separado, las aplicaciones creadas utilizando el patrón de arquitectura de microservicios son generalmente más robustas, proporcionan una mejor escalabilidad y pueden soportar más fácilmente la entrega continua.

Otra ventaja de este patrón es que proporciona la capacidad de realizar despliegues de producción en tiempo real, lo que reduce significativamente la necesidad de los tradicionales despliegues mensuales o de fin de semana de "big bang". Dado que el cambio se suele aislar a componentes de servicio específicos, sólo es necesario desplegar los componentes de servicio que cambian. Si sólo tiene una única instancia de un componente de servicio, puede escribir código especializado en la aplicación de interfaz de usuario para detectar un despliegue en caliente activo y redirigir a los usuarios a una página de error o una página de espera. Alternativamente, puede intercambiar varias instancias de un componente de servicio durante y después de una implementación en tiempo real, lo que permite una disponibilidad continua durante los ciclos de implementación (algo que es muy difícil de hacer con el patrón de arquitectura en capas).

Una última consideración a tener en cuenta es que, dado que el patrón de arquitectura de los micro-servicios es una arquitectura distribuida, comparte algunos de los mismos problemas complejos encontrados en el patrón de arquitectura impulsado por eventos, incluyendo creación de contrato, mantenimiento y administración, disponibilidad remota del sistema, autenticación y autorización de acceso remoto.

SOAP vs REST

Mucho se a dicho de Rest y SOAP pero siempre es bueno aclarar las diferencias entre Rest y SOAP. A mi entender las diferencias son muchas, y no se mezclan, es decir el objetivos de su creación es totalmente diferentes.

Aprovecho y les dejo este cuadrito:

Dejo link:
http://javarevisited.blogspot.sg/2015/08/difference-between-soap-and-restfull-webservice-java.html

MySQL ofrece una API REST

Si, si, MySQL ofrece una API REST. Toma tu torta! leyendo infoQ me encontré con la noticia de que existe un plugin, para agregar una API REST, este plugin se encuentra en MySql labs.

Esta API nos permite acceder a nuestra información por medio de REST. De hecho lo que hacemos es hacer una consulta con una url:

SQL: SELECT * FROM simple ORDER BY id
URL: http://127.0.0.1:8080/sql//SELECT+%2A+FROM+simple+ORDER+BY+id

Además se puede hacer CRUD, y se puede utilizar JSON.

Dejo link: http://www.infoq.com/news/2014/09/MySQL-REST

Retrofit, haciendo fácil el acceso a servicios rest desde android.

Retrofit es un framework que nos hace fácil la vida cuando desarrollamos aplicaciones Android. Supongamos que mi aplicación tiene una API Rest y otra aplicación Android se conecta y consume datos de dicha API. Retrofit nos hace muy fácil el acceso a esta API usando Android.

Retrofit nos permite consumir servicios Rest por medio de anotaciones y de la misma forma que los desarrollamos, lo que hace que la curva de aprendizaje sea casi nula. A la vez popula nuestros objetos desde json o xml.

Veamos un ejemplo:

@Multipart
@PUT("/user/photo")
User updateUser(@Part("photo") TypedFile photo, @Part("description") TypedString description);

Además nos provee control de cabeceras:

@Headers("Cache-Control: max-age=640000")
@GET("/widget/list")
List<Widget> widgetList();

@Headers({
    "Accept: application/vnd.github.v3.full+json",
    "User-Agent: Retrofit-Sample-App"
})
@GET("/users/{username}")
User getUser(@Path("username") String username);

Si usamos maven la dependencia es:

<dependency>
  <groupId>com.squareup.retrofit</groupId>
  <artifactId>retrofit</artifactId>
  <version>1.6.1</version>
</dependency>

Dejo link:
http://square.github.io/retrofit/

Entendiendo el principio HATEOAS

HATEOAS es la abreviación de Hypermedia as the Engine of Application State (hipermedia como motor del estado de la aplicación). Es una restricción de la arquitectura de la aplicación REST que lo distingue de la mayoría de otras arquitecturas. El principio es que un cliente interactúa con una aplicación de red completamente a través de hipermedia proporcionadas dinámicamente por los servidores de aplicaciones. Es como que el cliente REST debe ir navegando por la información y no necesita ningún conocimiento previo acerca de la forma de interactuar con cualquier aplicación o servidor más allá de una comprensión genérica de hipermedia.

En otras palabras cuando el servidor nos devuelva la representación de un recurso parte de la información devuelta serán identificadores únicos en forma de hipervínculos a otros recursos asociados.

Lo vamos a entender mejor con un ejemplo, supongamos que tenemos una API REST, con cliente y sus diferentes pedidos. El modelo podría ser un cliente que tenga una lista de pedidos.

Lo que podríamos hacer es cuando el cliente REST solicite un cliente por la URI:

myURL/cliente/:id

Devolvemos los datos del cliente con su lista de pedidos. Pero el problema yace en que tal vez tenga muchos pedidos y a la vez el cliente REST necesita datos del cliente no de los pedidos. Por lo tanto, estoy mostrando más información de lo que debiera.

Una solución sería tener otro servicio REST que me devuelva los pedidos, por ejemplo:

myURI/cliente/2

Esta URI me devolverá los datos del cliente 2 que podría ser:

{ id:2, nombre:”Pepe”, apellido:”Gomez” }

Y podríamos hacer otro servicio que nos devuelva los pedidos por medio de la URI:

myURI/cliente/2/pedidos

Supongamos que por algún problema debemos cambiar la URI de pedidos, para hacer esto  debemos avisar a todos los clientes y ellos deberán consumir la nueva URI.

HATEOAS nos dice que debemos mostrar las URIs de forma que el cliente este menos acoplado al servidor y no sea necesario hacer cambios en estos casos.

Por ejemplo el servicio de consulta de clientes puede devolver la URI del pedido de la siguiente manera:

{ id:2, nombre:”Pepe”, apellido:”Gomez” , pedidos:”myURL/cliente/2/pedidos ”}

A la vez si no mostramos la URI de los pedidos el cliente REST tiene que ir a la documentación de la API por cada servicio que desee utilizar. Con HATEOAS los servicios descubren nuevos servicios lo que permite navegar por la información y un cliente que una URI principal puede ir descubriendo los demás servicios.  

La restricción HATEOAS desacopla cliente y el servidor de una manera que permite la funcionalidad del servidor para evolucionar de forma independiente.

Dejo link: http://en.wikipedia.org/wiki/HATEOAS

Hacer una Api Rest con haskell es posible gracias a rest

Parece un juego de palabras pero no lo es rest es un framework (en la documentación dice conjunto de paquetes) que permiten hacer una Api Rest con Haskell.

A la vez se puede ejecutar estas librerías en varios frameworks web, como Happstack o Snap. También puede generar automáticamente la documentación de la API Rest, lo que garantiza que siempre coincide con el código. Del mismo modo, puede generar cliente para diferentes lenguajes como Javascript o Haskell.

Algo muy bueno es que la Api queda escrita como en un DSL muy fácil de mantener, veamos un ejemplo:

module Api.Post (resource) where

import Rest
import qualified Rest.Resource as R

type Title = String

resource :: Resource IO (ReaderT Title IO) Title () Void
resource = mkResourceReader
  { R.name   = "post"
  , R.schema = withListing () $ named [("title", singleBy id)]
  , R.list   = const list
  , R.get    = Just get
  }

Dejo link:
http://silkapp.github.io/rest/
https://github.com/silkapp/rest/archive/master.zip

Documetando APIs Rest con Swagger

Te imaginas un javadoc de tus servicios REST? Swagger es eso y mucho más dado que es una herramienta extremadamente útil para describir, producir, consumir y visualizar APIs RESTful. El principal objetivo de este framework es enganchar el sistema de documentación con el código del servidor para que esté sincronizado a cada cambio. Casi documentamos al mismo tiempo que creamos la implementación.

Swagger está desarrollado de tal modo que podemos usar Scala, Java, Javascript, Ruby, PHP o ActionScript para generar toda la documentación y su sandbox correspondiente. Además, existen distintos módulos para enganchar a nuestros proyecto Node.js, Grails, Scala Play, Spring MVC, Symfony o Ruby, entre otros muchos.

Los usuarios de las APIS también son beneficiados ya que proporciona una interfaz visual a modo de sandbox donde podemos testear la llamadas del API, además de consultar su documentación. Podéis echar un vistazo a un ejemplo de la web que genera Swagger a partir del código de nuestra API con los métodos, parámetros y modelos de JSON que devuelve.

Swagger es perfecto para tener la documentación de nuestras APIs a punto y brindarle un servicio más a los clientes con ejemplos.

The Swagger™ Specification: https://github.com/wordnik/swagger-spec
Swagger™ Demo: http://petstore.swagger.wordnik.com/
Downloads: https://github.com/wordnik/swagger-core/wiki/Downloads

Rest con PHP, más fácil imposible!!

Me toco diseñar una API REST con PHP y la verdad me da vergüenza decir que trabaje, porque es sumamente fácil,lo primero hacemos nuestra función PHP, para el ejemplo un listado de paises:

    $db = new DB(); //Con este objeto me conecto a la base
    $db->conectar();
    $sql = 'SELECT * FROM `paises` ORDER BY `nombre`'; //Listo los paises por ejemplo
    $consulta = $db->query($sql);

    while ($fila = mysql_fetch_array($consulta)) {
        $paises[] = $fila;  
    }
    $data["paises"] = $paises;
    echo json_encode($data); // lo imprimo formato json.

Y listo, claro que no es rest puro pero es util para publicar una función. Si quieren usar Rest puro pueden usar el metodo $_SERVER['REQUEST_METHOD'] y de esta forma saber el metodo, y si tenemos un controlador podemos hacer:

$method = $_SERVER['REQUEST_METHOD'];

// Dependiendo del método de la petición ejecutaremos la acción correspondiente.

switch ($method) {
    case 'GET':
        // código para método GET
        break;
    case 'POST':
        $arguments = $_POST;
        // código para método POST
        break;
    case 'PUT':
         // código para método PUT
        break;
    case 'DELETE':
        // código para método DELETE
        break;
}

Y esto lo podemos consumir con javascript y si usamos jquery es una papa:

           $.ajax({

                       type: "GET",

                       dataType: "JSON",

                       url: "listar_paises",                                        

                       success: function(data)                                 

                       { //hacer algo

                       },

                       error: function() 

                       {       alert("Error recuperando la lista de Paises");

                       }                

                });

Y listo!!

PouchDB un base de datos web inspirada en Apache CouchDB

PouchDB es una librería JavaScript que permite almacenar y consultar datos para aplicaciones web que necesitan trabajar sin conexión para luego sincronizar con una base de datos en línea.

Inspirada en Apache CouchDB, PouchDB es una pequeña base de datos web y en especial para aplicaciones móviles que necesitan guardar datos en una base basada en el browser que puede ser usado offline. La base de datos se puede sincronizar con CouchDB o otra base cuando este online.

Al igual que Apache CouchDB, tiene una API HTTP basada en REST y JSON que permite guardar objetos JSON.

Actualmente PouchDB es una librería javascript de 131 kb comprimido. Que puede realizar las siguientes tareas: crear/consultar/replicar/borrar una base de datos; crear/buscar/actualizar/borrar documento(s) recuperar información de bases de datos y además tiene un listener de los cambios de base de datos.   La base de datos también viene con un adaptador de HTTP REST que se puede utilizar para sincronizar su contenido CouchDB / PouchDB. Que más queres que te haga pochoclos?

PouchDB usa la API IndexedDB  de  HTML 5  para acceder al storage del browser actualmente  SQLite in Firefox and LevelDB in Chrome. PouchDB fue probado en Firefox 12 y chrome 19.

Veamos un poco de código:

var authors = [
  {name: 'Dale Harvey', commits: 253},
  {name: 'Mikeal Rogers', commits: 42},
  {name: 'Johannes J. Schmidt', commits: 13},
  {name: 'Randall Leeds', commits: 9}
];
Pouch('idb://authors', function(err, db) {
  // Opened a new database
  db.bulkDocs({docs: authors}, function(err, results) {
    // Saved the documents into the database
    db.replicate.to('http://host.com/cloud', function() {
      // The documents are now in the cloud!
    });
  });
});

Esto es una genialidad!!

Dejo Link:

http://pouchdb.com/

SOAP vs REST: ¿Cual usar en cada caso?

Desde que REST salió a la luz, siempre ha habido un debate en torno a su comparación con SOAP. La arquitectura REST es sencilla, precisamente ese es su atractivo principal.

REST fue rápidamente catalogado como alternativa a SOAP. Aún así, actualmente SOAP todavía posee el monopolio en el mundo de los Servicios Web. Ambos difieren en muchos aspectos comenzando por que REST fue concebido en el ámbito académico y SOAP es un estándar de la industria, creado por un consorcio del cual Microsoft formaba parte.

Las principales diferencias en el funcionamiento de ambos son:

• SOAP es un estilo de arquitectura orientado a RPC (Remote Procedure Call), es decir, un estilo basado en llamadas a procedimientos remotos, mientras que para REST solamente existen los métodos de HTTP y está orientado a recursos.
• REST no permite el uso estricto de “sesión” puesto que por definición es sin estado, mientras que para SOAP, al ser orientado a RPC, los servicios Web crean sesiones para invocar a los métodos remotos.
• SOAP utiliza HTTP como un túnel por el que pasa sus mensajes, se vale de XML para encapsular datos y funciones en los mensajes. Si dibujásemos una pila de protocolos, SOAP iría justo encima de HTTP, mientras que REST propone HTTP como nivel de aplicación.

En el debate de comparación entre REST y SOAP, la mayoría de los desarrolladores de aplicaciones Web toman posiciones muy extremas a favor de uno u otro. Los afines a SOAP, suelen pronunciarse diciendo que SOAP es más flexible que REST a la hora de implementar servicios Web y muestran como un defecto de REST la restricción “sin estado”, mientras que los adeptos de REST (también llamados Restafarians), critican la escasa transparencia de SOAP y opinan que hace las cosas más difíciles de lo que de verdad son, dicen que SOAP da “un paso hacia delante y dos hacia atrás”. Además opinan que SOAP puede suponer un problema porque puede dar lugar a la creación de agujeros de seguridad en las implementaciones HTTP.

Yo personalmente creo que los dos son utiles y se debe buscar la mejor herramienta para cada caso, dejo un link sobre este tema:

http://www.estebanetayo.es/?p=438

Consumir servicios JSON and REST con jQuery

La verdad es que la simplicidad de jQuery me sorprende. Como recordamos en post anteriores habíamos hecho servicios REST que eran expuestos con Json:

http://emanuelpeg.blogspot.com/2011/07/rest-con-cxf.html
http://emanuelpeg.blogspot.com/2011/06/resteasy-con-spring.html

Ahora vamos a consumirlos con jQuery:

$.getJSON(url, function(data) {

   //data es el objeto Json, con el que obtengo los datos
   //Vamos a recorrerlo y mostrarlo
   $.each(data, function(index, objetoDelListado) {
          $("#algunaDiv").append(objetoDelListado.name);
});
});

Y listo!

Increíble!

Rest con CXF

Apache CXF es un framework open source, que nos permite construir servicios web tanto soap como rest. Su principal característica es que esta integrado total mente con spring.

Lo que vamos a hacer es exponer un bean de spring con cxf usando Rest y json.

Primero debemos agregar los siguientes jars, es bueno usar maven por lo tanto dejo la entrada del pom:

  


org.apache.cxf
cxf-rt-frontend-jaxws
${cxf.version}



org.apache.cxf
cxf-rt-transports-http
${cxf.version}




org.apache.cxf
cxf-rt-transports-http-jetty
${cxf.version}



org.apache.cxf
cxf-bundle-jaxrs

${cxf.version}

 
  org.eclipse.jetty
  jetty-server
 






  
  
   org.codehaus.jackson
   jackson-mapper-asl
   ${jackson.version}
  
  
  
   org.codehaus.jackson
   jackson-jaxrs
   ${jackson.version}
  
  
  
   org.codehaus.jackson
   jackson-xc
   ${jackson.version}
  

Las versiones de los framework pueden buscarlas en mvnrepository.com. En el caso de cxf depende también la versión de spring, con spring 2.5 se usa hasta 2.3.5; si queres usar versiones mas nuevas deberás usar spring 3.

Luego debemos agregar la siguiente entrada al web.xml:

 
CXFServlet
CXF Servlet

org.apache.cxf.transport.servlet.CXFServlet
              
1



CXFServlet
/rest/*

Ojo que tienen que levantar spring en el web.xml, si ya lo hacen esta todo bien, si no deben agregar la siguiente linea en el web.xml:

    contextConfigLocation
    /WEB-INF/applicationContext-hibernate.x
ml

...

      context
      
    org.springframework.web.context.ContextLoaderServlet
      
    1

Luego de esto vamos a escribir nuestro bean, yo no voy a hacer una interfaz para este bean pero es bueno que si pueden la hagan.

package org.assembly.post;

import javax.ws.rs.GET;
import javax.ws.rs.Path;


/**
* @author emanuel
*/
@Path("/posts")
public class PostsRest {

@GET
public String getPosts() {
return "posts";
}


}

Este bean tiene un método que solo devuelve un string. Ahora vamos a definir el bean en el applicationContext.xml de sprint y además configurar el servicio REST:

Se deben incluir estos archivos de cxf para que funcione el framework estos archivos son del framework, así que no hay problema por eso.

Como vemos primero se define el servicio Rest y luego se define el bean.

Si vamos a la url http://localhost:8080//rest/posts nos devolverá el string "post".

Y no iba a usar Json? Si si, para un cachito. Ahora vamos a devolver un objeto por json.Para esto vamos a usar un framework llamado Jackson.

Vamos a modificar nuestro bean para uqe tenga como provider Jackson :

Luego modificamos nuestra clase para tener métodos donde podamos devolver json:

package org.assembly.nornas.web.rest.post;

import java.util.List;

import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.PathParam;
import javax.ws.rs.Produces;

import org.assembly.dto.post.PostDTO;
import org.assembly.nornas.service.post.PostService;


/**
*
*
* @author emanuel
*/
@Path("/posts")
public class PostsRest {

private PostService postService;

public void setPostService(PostService postService) {
this.postService = postService;
}

@GET
@Path("/{blogId}/{from}")
@Produces("application/json")
public PostDTO findPostsPublishedByBlogId(@PathParam("blogId") Long blogId, @PathParam("from") Integer from) {
PostDTO post = new Post(1,"hola Mundo","Este es mi Hola Mundo");
return post;
}

 @GET
 @Produces("application/json")
 @Path("/test")
 public List< String> test() {
  List< String> strings = new ArrayList< String>();
  strings.add("hola");
  strings.add("mundo");
  return strings;
 }

}

PostDTO esta anotado con anotaciones de jaxb para generar el objeto json correctamente:

@XmlRootElement(name="post")
public class PostDTO implements Serializable {

private static final long serialVersionUID = -6319037835355763839L;
@XmlElement(name="id")
private Long id;
@XmlElement(name="title")
private String title;
@XmlElement(name="content")
private String content;

//geters y seters
}

Ojo Jaxb necesita el constructor por defecto.

Luego vamos a la URL http://localhost:8080//rest/posts/1/0 por ejemplo.

Si vamos al método test http://localhost:8080//rest/test nos devolverá lo siguiente:

["hola","mundo"]


Y listo!!

Dejo Links:

http://cxf.apache.org/docs/jax-rs.html

http://architects.dzone.com/articles/putting-java-rest

http://blog.wolfgang-werner.net/restful-http-with-jax-rs/

RESTEasy con Spring

RESTEasy es un framework de jboss que nos ayuda a generar servicios RESTfull. Este framework es una implementación de JAX-RS (JSR 311). JAX-RS es una nueva especificación de jcp que provee una API para servicios RESTfull bajo el protocolo http.

Anteriormente ya hablamos de este framework:

http://emanuelpeg.blogspot.com/2009/11/resteasy.html

Rápidamente pasemos a ver un ejemplo, quiero exponer un servicio por medio de rest con spring.

Primero agregamos la entrada en el pom (usemos maven please)

         org.jboss.resteasy
         resteasy-jaxrs
         2.2.0.GA
     
  
     
         org.codehaus.jettison
         jettison
     
  
     
         org.jboss.resteasy
         resteasy-jettison-provider
         2.2.0.GA
     
     
     org.jboss.resteasy
     resteasy-spring
     2.2.0.GA
 

Para que estas funcionen hay que agregar los siguientes repositorios en el pom:

 
         java.net
         http://download.java.net/maven/1
         legacy
     
     
         maven repo
         maven repo
         http://repo1.maven.org/maven2/
     
     
     
         jboss
         jboss repo
         http://repository.jboss.org/nexus/content/groups/public/
     

Además el web.xml queda similar a este:

RestEasy con Spring


  org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap


  org.jboss.resteasy.plugins.spring.SpringContextLoaderListener



  Resteasy
  org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher



  Resteasy
  /serviciosRest/*

Ahora vamos a hacer anotar nuestro servicio para que funcione con rest:

@Path("/posts")
public interface HolaMundoService {
 
 @GET
 public String getSaludo();
}

Luego debemos implamentar este servicio y hacer un bean de spring.

Luego de hacer esto ya tenemos nuentro servicio rest en http://localhost:port//serviciosRest/posts

RESTEasy esta bajo licencia Apache ASL 2.0 y es una perfecta opción compatible con Spring.

Dejo links:

http://docs.jboss.org/resteasy/docs/2.2.1.GA/userguide/html_single/index.html

http://community.jboss.org/docs/DOC-13709?uniqueTitle=false

UrlRewrite

Una buena practica en publicar nuestras url en formato restful. Donde los datos de la consulta son parte de la url, esto mayor aceptación de parte del usuario y los buscadores. Por ejemplo mi sitio publica el profile de mis usuarios, si quiesiera publicar el profile de Juan su url sería algo así:

http://misitio.com/profile/juan

Esto es más amigable que esto:

http://misitio.com/profile?name=juan

Creo que en esto estamos todos deacuerdo.

Muchas veces en nuestros proyectos java no podemos hacer esto, dado que el framework web no lo permite. Para estos casos existe UrlRewrite, que permite reescribir nuestras url como queramos; ojo no solo se puede usar para url restful sino para cualquier cambio que quisiéramos hacer a nuestras urls.

Primero bajamos el jar o si usamos maven agregamos esto en el pom.xml

 
 
  org.tuckey
  urlrewritefilter
  3.1.0
 

Luego tenemos que agregar el siguiente filtro en el archivo web.xml :

 UrlRewriteFilter
 org.tuckey.web.filters.urlrewrite.UrlRewriteFilter


 UrlRewriteFilter
 /*

Ahora debemos escribir un archivo que contenga el cambio de las urls, el archivo se debe llamar urlrewrite.xml:

    
       /profile/([a-z]+)$
       /misitio/profile/index.htm?name=$1
    

En el archivo podemos ver que existe un from (la url que escribe el usuario) y un to(la url real de nuestro sistema) con $1 estamos indicando que el primer parámetro va a la variable de la url destino.

De esta foma armamos nuestras url para que queden más bonitas.

Dejo links:

http://www.tuckey.org/urlrewrite/
http://urlrewritefilter.googlecode.com/svn/trunk/src/doc/manual/3.2/index.html

RestTemplate en Spring 3

La clase RestTemplate es la principal clase de spring para acceso http del lado cliente. Conceptualmente es similar a JdbcTemplate, JmsTemplate y a otros templates proveídos por spring.

Los principales metodos del template tienen el nombre de los metodos Http:

HTTP RestTemplate

DELETE delete(String, String...)

GET getForObject(String, Class, String...)

HEAD headForHeaders(String, String...)

OPTIONS optionsForAllow(String, String...)

POST postForLocation(String, Object, String...)

PUT put(String, Object, String...)

Estos nombres indican claramente cuál de los métodos Http son invocados, mientras la segunda parte indica que devuelven los métodos. Por ejemplo getForObject() usa el método GET y transforma la respuesta HTTP en un objeto que decida. Como se puede apreciar los métodos se enfocan en las mejores prácticas REST.

Cada uno de los métodos tiene un parámetro de tipo string (el primero) este es la URI del método. Se puede pasar parámetros de dos formas una usando varargs:

String result = restTemplate.getForObject("http://example.com/hotels/{hotel}/bookings/{booking}", String.class, "42", "21");

Esto debería llamar a http://example.com/hotels/42/bookings/21 por el método GET.

También podemos usar mapas, por ejemplo:

Map vars = new HashMap();

vars.put("hotel", "42");

vars.put("booking", "21");

String result = restTemplate.getForObject("http://example.com/hotels/{hotel}/bookings/{booking}", String.class, vars);

Esto debería llamar a http://example.com/hotels/42/rooms/42 también por el método GET.

HttpMessageConverters se encarga de convertir los HTTP requests a los tipos que se indiquen.

RESTEasy

Es un proyecto de jboss que provee una implementación a jsr 311. Este proyecto contiene un conjunto de frameworks que nos facilitan el desarrollo con web services rest.

Jsr 311 nos permite desarrollar y publicar web services rest con anotaciones, vean que fácil es:

@Path("/library")

public class Library {

@GET

@Path("/books")

public String getBooks() {...}

@GET

@Path("/book/{isbn}")

public String getBook(@PathParam("isbn") String id) {

// search my database and get a string representation and return it

}

@PUT

@Path("/book/{isbn}")

public void addBook(@PathParam("isbn") String id, @QueryParam("name") String name) {...}

@DELETE

@Path("/book/{id}")

public void removeBook(@PathParam("id") String id {...}

}

Recuerden que los web services rest no tienen un descriptor wsdl como los soap, sino que lo que describe a los servicios rest en la url y el método por donde se aceden.

@PUT, @DELETE, @GET, etc decimos el método y con @Path indicamos el path donde esta publicado.

RESTeasy puede ejecutarse sobre cualquier contenedor web.

Rest con Restlet

Restlet es un framework que lleva el concepto de los servlet para generar servicios web. Si vamos a una definición de Rest (http://diegograf.blogspot.com/2009/08/una-alternativa-mas-simple-soap-en-lo.html) veremos que la idea principal es hacer servicios web simples.

La simpleza puede verse de quien consume el servicio web. Restlet hace simple el desarrollo de web services. Veamos un “hola Mundo” usando Restlet 2.0

1. package firstSteps;

2.

3. import org.restlet.resource.Get;

4. import org.restlet.resource.ServerResource;

5.

6. /**

7. * Resource which has only one representation.

8. *

9. */

10. public class HelloWorldResource extends ServerResource {

11.

12. @Get

13. public String represent() {

14. return "hello, world";

15. }

16.

17. }

Vemos que hemos creado un recurso el cual se va a publicar por medio del método GET. Ahora hagamos una aplicación:

1. package firstSteps;

2.

3. import org.restlet.Application;

4. import org.restlet.Restlet;

5. import org.restlet.routing.Router;

6.

7. public class FirstStepsApplication extends Application {

8.

9. /**

10. * Creates a root Restlet that will receive all incoming calls.

11. */

12. @Override

13. public Restlet createRoot() {

14. // Create a router Restlet that routes each call to a

15. // new instance of HelloWorldResource.

16. Router router = new Router(getContext());

17.

18. // Defines only one route

19. router.attach("/hello", HelloWorldResource.class);

20.

21. return router;

22. }

23. }

Como vemos creamos un router el cual es el encargado de publicar nuestro servicio web. Ahora configuramos el contexto para que cuando le enviemos un pedido a una URL, nuestro servidor lo delegue al servlet de rest.

1. <?xml version="1.0" encoding="UTF-8"?>

2. <web-app id="WebApp_ID" version="2.4"

3. xmlns="http://java.sun.com/xml/ns/j2ee"

4. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

5. xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee

6. http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">

7. <display-name>first steps servlet</display-name>

8.

9. <context-param>

10. <param-name>org.restlet.application</param-name>

11. <param-value>

12. firstSteps.FirstStepsApplication

13. </param-value>

14. </context-param>

15.

16.

17. <servlet>

18. <servlet-name>RestletServlet

19. <servlet-class>

20. org.restlet.ext.servlet.ServerServlet

21. </servlet-class>

22. </servlet>

23.

24. <!-- Catch all requests -->

25. <servlet-mapping>

26. <servlet-name>RestletServlet</servlet-name>

27. <url-pattern>/*</url-pattern>

28. </servlet-mapping>

29. </web-app>

Bueno con eso estamos, mmm…

Todavía nos faltan los jars por suerte se pueden importar con maven. Dejo el link para configurar el repositorio de restlet http://www.restlet.org/downloads/maven

Si no podemos instalar los jars necesitamos 2 :

org.restlet.jar

org.restlet.ext.servlet_2.5.jar

Lo pueden bajar de http://www.restlet.org/downloads/2.0/restlet-jse-2.0m4.zip e instalar de esta forma :

mvn install:install-file -DgroupId=org.restlet -DartifactId= org.restlet -Dversion=2.0.0 -Dpackaging=jar -Dfile=dondeDejasteElJar/elJar.jar

mvn install:install-file -DgroupId=org.restlet -DartifactId= org.restlet.ext -Dversion=2.0.0 -Dpackaging=jar -Dfile=dondeDejasteElJar/elJar.jar

1. <dependency>

2. <groupId>org.restlet</groupId>

3. <artifactId>org.restlet</artifactId>

4. <version>2.0.0</version>

5. </dependency>

6. <dependency>

7. <groupId>org.restlet</groupId>

8. <artifactId>org.restlet.ext</artifactId>

9. <version>2.0.0</version>

10. </dependency>

Levanten el jetty o tomcat y luego http://127.0.0.1/contexto/ hello y hay esta nuestro servicio!!