Posts com Tags Web-services

Aplicações RESTful HATEOAS com SpringBoot


O HATEOAS, é uma das principais constraints arquiteturais do REST e possibilita a navegação entre recursos, que são representações dos modelos de negócio da aplicação. Esse post é bem mão na massa e se quiser aprofundar um pouco mais em conceitos teóricos de HATEOAS confira o nosso post Entendendo HATEOAS. Vamos tomar como base a aplicação desenvolvida no nosso outro post Documentando aplicações REST com SpringBoot e Swagger. Para começar você pode baixar o código deste post aqui e descompactar o arquivo zip e importar na sua IDE preferida ou clonar usando Git:


git clone https://github.com/leandrocgsi/simple-rest-example-swagger.git


Primeiro altere o pom.xml adicionando os trechos destacados por comentários abaixo.


<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    
    <groupId>br.com.erudio</groupId>
    <artifactId>simple-rest-example-hateoas</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>1.3.3.RELEASE</version>
    </parent>
    
    <dependencies>
        
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>
        
        <!-- Adicione a dependencia de HATEOAS-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-hateoas</artifactId>
        </dependency>
        
        <dependency>
            <groupId>com.mangofactory</groupId>
            <artifactId>swagger-springmvc</artifactId>
            <version>1.0.0</version>
        </dependency>
        <dependency>
            <groupId>org.ajar</groupId>
            <artifactId>swagger-spring-mvc-ui</artifactId>
            <version>0.4</version>
        </dependency>
        <dependency>
            <groupId>org.apache.tomcat.embed</groupId>
            <artifactId>tomcat-embed-jasper</artifactId>
            <scope>provided</scope>
        </dependency>
        
        <!-- Adicione as dependencias de teste -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>com.jayway.jsonpath</groupId>
            <artifactId>json-path</artifactId>
            <scope>test</scope>
        </dependency>        
        
    </dependencies>

    <properties>
        <java.version>1.8</java.version>
    </properties>
    
    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>
    
    <repositories>
        <repository>
            <id>spring-releases</id>
            <url>https://repo.spring.io/libs-release</url>
        </repository>
        <repository>
            <id>jcenter-release</id>
            <name>jcenter</name>
            <url>http://oss.jfrog.org/artifactory/oss-release-local/</url>
        </repository>
    </repositories>
    
    <pluginRepositories>
        <pluginRepository>
            <id>spring-releases</id>
            <url>https://repo.spring.io/libs-release</url>
        </pluginRepository>
    </pluginRepositories>
    
</project>


Primeiro vamos alterar a classe Greeting que agora ira extender ResourceSupport.


package br.com.erudio.models;

import org.springframework.hateoas.ResourceSupport;

import com.fasterxml.jackson.annotation.JsonCreator;
import com.fasterxml.jackson.annotation.JsonProperty;

public class Greeting extends ResourceSupport {

    private final long idGreeting;
    private final String content;

    @JsonCreator
    public Greeting(@JsonProperty("id") long id, @JsonProperty("content") String content) {
        this.idGreeting = id;
        this.content = content;
    }

    public long getIdGreeting() {
        return idGreeting;
    }

    public String getContent() {
        return content;
    }
}


Agora adicione os trechos comentados a classe GreetingController.


package br.com.erudio.web.controllers;

import static org.springframework.hateoas.mvc.ControllerLinkBuilder.linkTo;
import static org.springframework.hateoas.mvc.ControllerLinkBuilder.methodOn;

import java.util.concurrent.atomic.AtomicLong;

import org.springframework.http.HttpEntity;
import org.springframework.http.HttpStatus;
import org.springframework.http.MediaType;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.ResponseStatus;
import org.springframework.web.bind.annotation.RestController;

import com.wordnik.swagger.annotations.Api;
import com.wordnik.swagger.annotations.ApiOperation;

import br.com.erudio.models.Greeting;

@Api(value = "greeting")
@RestController
@RequestMapping("/greeting")
public class GreetingController {

    private static final String template = "Hello, %s!";
    private final AtomicLong counter = new AtomicLong();

	@ApiOperation(value = "Show Greeting Message" )
	@ResponseStatus(HttpStatus.OK)
    @RequestMapping(method = RequestMethod.GET, produces = MediaType.APPLICATION_JSON_VALUE)
    public HttpEntity<Greeting> greeting(@RequestParam(value="name", defaultValue="World") String name) {
		Greeting greeting = new Greeting(counter.incrementAndGet(), String.format(template, name));
		
		// Na prática essa linha adiciona uma auto referência ao próprio endpoint
		// e apenas esse pequeno trecho de código já é o suficiente para que o endpoint 
		// greeting seja HATEOAS
		greeting.add(linkTo(methodOn(GreetingController.class).greeting(name)).withSelfRel());
        
		return new ResponseEntity<Greeting>(greeting, HttpStatus.OK);
    }
}


Se você iniciar a aplicação e acessar o endereço localhost:8080/greeting verá algo similar a imagem abaixo.

postagem_4_0


package br.com.erudio.models;

import java.io.Serializable;

import org.springframework.hateoas.ResourceSupport;

import com.fasterxml.jackson.annotation.JsonIgnoreProperties;

// Adicione a anotação @JsonIgnoreProperties
@JsonIgnoreProperties(ignoreUnknown = true)

//Extenda ResourceSupport
public class Person extends ResourceSupport implements Serializable{
    
    private static final long serialVersionUID = 1L;
    
	// Por padrão implementação HATEOAS do Spring tem um atributo id
	// como default por isso o ID de nossa entidade deve ser alterado
    private Long idPerson;
    private String firstName;
    private String lastName;
    private String address;
    
    public Person() {}

	public Long getIdPerson() {
        return idPerson;
    }
    
    public void setIdPerson(Long id) {
        this.idPerson = id;
    }
    
    public String getFirstName() {
        return firstName;
    }
    
    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }
    
    public String getLastName() {
        return lastName;
    }
    
    public void setLastName(String lastName) {
        this.lastName = lastName;
    }
    
    public String getAddress() {
        return address;
    }
    
    public void setAddress(String address) {
        this.address = address;
    }
}


Agora vamos alterar a classe PersonController:


package br.com.erudio.web.controllers;
 
import static org.springframework.hateoas.mvc.ControllerLinkBuilder.linkTo;
import static org.springframework.hateoas.mvc.ControllerLinkBuilder.methodOn;
 
import java.util.ArrayList;
import java.util.List;
 
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.http.HttpStatus;
import org.springframework.http.MediaType;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.ResponseStatus;
import org.springframework.web.bind.annotation.RestController;
 
import com.wordnik.swagger.annotations.Api;
import com.wordnik.swagger.annotations.ApiOperation;
 
import br.com.erudio.models.Person;
import br.com.erudio.services.PersonService;
 
@Api(value = "person")
@RestController
@RequestMapping("/person/")
public class PersonController {
     
    @Autowired
    private PersonService personService;
	@ApiOperation(value = "Find person by ID" )
    @ResponseStatus(HttpStatus.OK)
    @RequestMapping(value = "/{personId}", method = RequestMethod.GET, produces = MediaType.APPLICATION_JSON_VALUE)
    public Person get(@PathVariable(value = "personId") String personId){
        Person person = personService.findById(personId);
		
		//Adicione uma auto referencia ao método get do controller passando o ID como parâmetro
        person.add(linkTo(methodOn(PersonController.class).get(personId)).withSelfRel());
		return person;
    }
     
    .
    .
    .
     
}


Note que ao acessar esse recurso com uma ferramenta como o POSTman teremos uma resultado similar a imagem abaixo.


postagem_4_1


Agora vamos alterar o findAll:


package br.com.erudio.web.controllers;

import static org.springframework.hateoas.mvc.ControllerLinkBuilder.linkTo;
import static org.springframework.hateoas.mvc.ControllerLinkBuilder.methodOn;

import java.util.ArrayList;
import java.util.List;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.http.HttpStatus;
import org.springframework.http.MediaType;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.ResponseStatus;
import org.springframework.web.bind.annotation.RestController;

import com.wordnik.swagger.annotations.Api;
import com.wordnik.swagger.annotations.ApiOperation;

import br.com.erudio.models.Person;
import br.com.erudio.services.PersonService;

@Api(value = "person")
@RestController
@RequestMapping("/person/")
public class PersonController {
	
	@Autowired
	private PersonService personService;
	
	.
	.
	.
	
	@ApiOperation(value = "Find all persons" )
	@ResponseStatus(HttpStatus.OK)
	@RequestMapping(value = "/findAll", method = RequestMethod.GET, produces = MediaType.APPLICATION_JSON_VALUE)
	public List<Person> findAll(){
		List<Person> persons = personService.findAll();
		ArrayList<Person> personsReturn = new ArrayList<Person>();
		for (Person person : persons) {
			String idPerson = person.getIdPerson().toString();
			
			// Adicione uma referencia ao método get do controller passando o ID como parâmetro
			// isso é feito para todos os elementos da lista
			person.add(linkTo(methodOn(PersonController.class).get(idPerson)).withSelfRel());
			personsReturn.add(person);
		}
		return personsReturn;
	}
	
	.
	.
	.
	
}


A imagem abaixo nos mostra o resultado dessa mudança. A nossa lista nos tras referencias únicas para cada um dos recursos.


postagem_4_2


Agora vamos adicionar o suporte a HATEOAS ao verbo POST da nossa aplicação.


package br.com.erudio.web.controllers;

import static org.springframework.hateoas.mvc.ControllerLinkBuilder.linkTo;
import static org.springframework.hateoas.mvc.ControllerLinkBuilder.methodOn;

import java.util.ArrayList;
import java.util.List;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.http.HttpStatus;
import org.springframework.http.MediaType;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.ResponseStatus;
import org.springframework.web.bind.annotation.RestController;

import com.wordnik.swagger.annotations.Api;
import com.wordnik.swagger.annotations.ApiOperation;

import br.com.erudio.models.Person;
import br.com.erudio.services.PersonService;

@Api(value = "person")
@RestController
@RequestMapping("/person/")
public class PersonController {
	
	@Autowired
	private PersonService personService;
	
	.
	.
	.
	
	@ApiOperation(value = "Create a new person" )
	@ResponseStatus(HttpStatus.OK)
	@RequestMapping(method = RequestMethod.POST, consumes = MediaType.APPLICATION_JSON_VALUE, produces = MediaType.APPLICATION_JSON_VALUE)
	public Person create(@RequestBody Person person){
		Person createdPerson = personService.create(person);
		String idPerson = createdPerson.getIdPerson().toString();
		
		// Após criarmos um novo recurso do tipo Person nós recuperamos seu ID e adicionamos
		// uma referencia ao método get do controller passando o ID como parâmetro		
		createdPerson.add(linkTo(methodOn(PersonController.class).get(idPerson)).withSelfRel());
		return createdPerson;
	}
	
	.
	.
	.
	
}


Como se pode ver na imagem após salvar uma nova pessoa a aplicação retorna um link para que as informações da mesma possam ser acessadas.


postagem_4_3


Agora vamos modificar o verbo PUT.


package br.com.erudio.web.controllers;

import static org.springframework.hateoas.mvc.ControllerLinkBuilder.linkTo;
import static org.springframework.hateoas.mvc.ControllerLinkBuilder.methodOn;

import java.util.ArrayList;
import java.util.List;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.http.HttpStatus;
import org.springframework.http.MediaType;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.ResponseStatus;
import org.springframework.web.bind.annotation.RestController;

import com.wordnik.swagger.annotations.Api;
import com.wordnik.swagger.annotations.ApiOperation;

import br.com.erudio.models.Person;
import br.com.erudio.services.PersonService;

@Api(value = "person")
@RestController
@RequestMapping("/person/")
public class PersonController {
	
	@Autowired
	private PersonService personService;
		
	.
	.
	.
	
	@ApiOperation(value = "Update an existing person")
	@ResponseStatus(HttpStatus.OK)
	@RequestMapping(method = RequestMethod.PUT,consumes = MediaType.APPLICATION_JSON_VALUE)
	public Person update(@RequestBody Person person){
		Person updatedPerson = personService.update(person);
		String idPerson = updatedPerson.getIdPerson().toString();
		
		// Após atualizarmos um recurso nós recuperamos seu ID e adicionamos
		// uma referencia ao método get do controller passando o ID como parâmetro		
		updatedPerson.add(linkTo(methodOn(PersonController.class).get(idPerson)).withSelfRel());		
		return updatedPerson;
	}
	
	.
	.
	.
	
}


Da mesma forma que com o verbo POST após atualizar uma pessoa a aplicação retorna um link para que as informações da mesma possam ser acessadas.


postagem_4_4


Como o verbo DELETE exclui um recurso não há necessidade de adicionar suporte a HATEOAS nele. Sendo assim fechamos a nossa implementação e podemos dizer que a nossa API é finalmente RESTful. Assim como nos posts anteriores você pode baixar o código deste post aqui e descompactar o arquivo zip e importar na sua IDE preferida ou clonar usando Git:

git clone https://github.com/leandrocgsi/simple-rest-example-hateoas.git


É isso aí bons estudos e continuem ligados no blog para mais novidades 😉


Tags: , , , , ,

Entendendo HATEOAS


HATEOAS (Hypermedia as the Engine of Application State) é uma constraint arquitetural de aplicações REST. Uma API HATEOAS provê informações que permite navegar entre seus endpoints de forma dinâmica visto que inclui links junto às respostas. Esta capacidade a difere de sistemas baseados em SOA e interfaces dirigidas por WSDL(pronuncia-se uísdou). Com SOA, servidores e clientes usualmente devem acessar uma especificação fixa que pode ser acessada em outro lugar na API, ou em um website, ou as vezes distribuído por email.


Nota: Pronunciar HATEOAS não é fácil e pode variar bastante. Algumas pessoas pronunciam algo como “riteos“, outros como “reitos” ou como “reidôs“. Alguns podem se referir a esse conceito arquitetural por hypermedia-driven system – algo como sistema dirigido por hipermídia.


Exemplos


O código a seguir representa um objeto Cliente.


class Cliente {
    String nome;
}


Uma representação JSON tradicional seria algo como:


{ 
    "nome" : "Leandro"
}


Os dados do Cliente estam lá, mas os dados não contém nada de relevante sobre suas conexões. Uma representação baseada em HATEOAS deve ser similar ao JSON abaixo:


{
    "nome": "Leandro",
    "links": [ {
        "rel": "self",
        "href": "http://localhost:8080/Cliente/1"
    } ]
}


A resposta não contém somente o nome de uma pessoa, mas inclui uma URL com o endereço de onde as informações dessa pessoa podem ser localizadas.
rel significa relacionamento. No nosso caso o link autoreferencia a pessoa. Sistemas mais complexos incluem outros tipos de relacionamentos. Por exemplo, uma ordem de compra pode ter um relacionamento com cliente”rel”:”Cliente” vinculando a ordem ao Cliente.
href é uma URL completa que define um único recurso.


Nota: Apesar de meus exemplos serem em JSON, XML também é aceito como um formato de resposta padrão. HATEOAS não impõe a exigência à um formato em específico. O seu foco é prover links que possibilite navegar entre os recursos de uma API.


Apesar de nossos exemplos serem bem simples é possível construir relações mais complexas. O HATEOAS, facilita aos desenvolvedores, de aplicações cliente, acessar os recursos de uma API sem precisar definir uma especificação, criar um documento externo ou uma wiki para isso.
Observe o JSON abaixo:


{
    "conteudo": [ {
        "preco": 499.00,
        "descricao": "HD Seagate 2TB",
        "nome": "HD S2TB",
        "links": [ {
            "rel": "self",
            "href": "http://localhost:8080/produto/1"
        } ],
        "atributos": {
            "conector": "SATA"
        }
    }, {
        "preco": 49.00,
        "descricao": "Mouse Óptico Dell",
        "nome": " Mouse",
        "links": [ {
            "rel": "self",
            "href": "http://localhost:8080/produto/3"
        } ],
        "atributos": {
            "conector": "wireless"
        }
    } ],
    "links": [ {
        "rel": "produto.consulta",
        "href": "http://localhost:8080/produto/consulta"
    } ]
}

Não apenas os itens e seus precos mostrados, mas também uma URL para cada recurso, fornecendo informações claras sobre como acessar cada recurso. De acordo com o modelo de maturidade de Richardson, HATEOAS é considerado o ultimo nível do REST. Isto significa que em uma aplicação HATEOAS presume-se que os verbos padrão de uma aplicação REST como GET, POST, PUT e DELETE também são adotados. Sendo que cada um deles, como é mostrado acima, provê ao cliente os links necessários ao acesso à uma informação.


É isso aí continuem ligados no blog e em breve teremos uma postagem bem mão na massa com HATEOAS e o nosso velho conhecido Spring Boot. Bons estudos 😉

Tags: , , ,

RESTful Web Services

Dando seqüência a série de postagens sobre Web-services neste post, discutiremos sobre a JAX-RS 2.0 a especificação para serviços baseados em RESTful. No mundo REST, você pode acessar tudo como um recurso e eles possuem um identificador único a URI(Uniform Resource Identifier). Um servidor REST e seus clientes interagem usando o protocolo HTTP e seus quatro verbos mais conhecidos que são:


POST – CREATE/para inserir recurso


O verbo HTTP POST é mais freqüentemente usado para criar novos recursos — inserir um novo item na base. Em uma aplicação REST perfeita quando uma operação é executada com sucesso, retorna-se o idempotente portanto seu uso não é recomendado quando se precisa desse tipo de comportamento em uma requisição. Fazendo duas requisições POST idênticas o resultado mais comum será duas respostas iguais com a mesma informação mas ocasionalmente essa resposta pode mudar.


GET – READ/para selecionar/recuperar um recurso


O verbo HTTP GET é usado para ler ou recuperar uma representação de um recurso. Em um “cenário feliz”, uma requisição GET retorna uma representação em XML ou JSON e um HTTP status code 200 (OK). Em um cenário de erro o retorno mais comum é 404 (NOT FOUND) ou 400 (BAD REQUEST).
De acordo com o design da especificação HTTP, o verbo GET (juntamente com o HEAD) é usado apenas para ler informações e não para alterá-la. Portanto quando usado dessa maneira é considerado seguro. Ou seja, ou seja eles podem ser invocados sem risco de perda ou corrupção de dados — chamando uma vez tem o mesmo efeito de chamá-lo 10 vezes, ou nenhuma. Além disso, o verbo GET (e HEAD) é idempotente, o que significa que se fizermos múltiplas requisições teremos sempre o mesmo resultado.
Você nunca deveria expor operações inseguras via GET — ele nunca deve ser usado para modificar informações no servidor.


PUT – UPDATE/para modificar um recurso


O verbo PUT é comumente usado para atualizar informações, colocando um recurso conhecido no (body) corpo da requisição contendo novas informações que representam o recurso original.
Entretanto, o verbo PUT também pode ser usado para criar um recurso caso o ID do mesmo seja definido pelo cliente ao invés do servidor. Em outras palavras se o verbo PUT é proveniente de uma URI que não contenha um recurso com um ID preexistente. Nesse caso o corpo da requisição contém a representação de um recurso. Para muitos isso pode parecer complicado e confuso. Conseqüentemente, este verbo deve ser usado com moderação para a criação de um novo recurso.
Uma alternativa para isso é utilizar o verbo POST para criar novos recursos com o ID definido pelo cliente setado no corpo da requisição — caso não tenha o ID definido para o recurso deve-se usar o verbo POST(confira acima).
Um update bem sucedido, retorna um status code 200 (ou 204 quando não retorna nenhum conteúdo no body. Se estiver usando o verbo PUT para criar um novo recurso, o retorno deve ser um status code 201 em caso de uma criação bem sucedida. O response body é opcional — lembrando que quando ele é exposto há um consumo maior de banda. Caso o cliente seja o responsável por definir o ID do recurso não é necessário retornar um link para o mesmo via location header.
O verbo PUT não é uma operação segura, na medida em que modifica(ou cria) um recurso no servidor, mas ele é idempotente. Em outras palavras, se você cria ou atualiza um recurso usando o verbo PUT e executa a mesma operação de novo, o recurso terá o mesmo estado que na primeira execução.
Se, por exemplo, você fizer uma requisição PUT para um recurso que incrementa um contador dentro de um recurso, a requisição perde o comportamento de idempotente. As vezes isso acontece sendo suficiente apenas documentar a requisição como não idempotente. Entretanto, o recomendado para requisições PUT é implementar apenas requisições idempotentes. Sendo assim é fortemente recomendado o uso do verbo POST para operações não idempotentes.


DELETE – DELETE/para remover um recurso


O verbo DELETE é fácil de entender, ele é usado para deletar um recurso identificado por uma URI.
Em uma deleção bem sucedida retorna-se um status code 200 (OK) juntamente com um response body, possivelmente uma representação do item deletado (o que acaba por demandar muita banda), ou uma response customizada. Ou retornar o status code 204 (NO CONTENT) sem response body. Em outras palavras, um status code 204 sem corpo, ou JSEND-style response com um status code 200 são as responses mais recomendadas.
As operações de DELETE são idempotentes. Se você deleta um recurso, ele é removido sendo impossível repetir a operação uma vez que o recurso não existe mais. Se você utilizar o verbo DELETE para decrementar um contador (dentro de um recurso), sua operação DELETE não será mais idempotente. Como dito anteriormente, estatísticas de uso e métricas podem ser atualizadas enquanto o serviço é considerado idempotente e as informações do recursos permanecem inalteradas. É recomendado o uso do verbo POST para operações não idempotentes.
Existe uma recomendação quanto a idempotência do DELETE entretanto repetir uma requisição de DELETE em um recurso, normalmente, retorna um status code 404 (NOT FOUND) uma vez que já foi removido e, portanto, não existe mais. Para muitos uma operação de DELETE não é idempotente, entretanto, o resultado final do recurso é o mesmo. Retornar um status code 404 é aceitável e comunica com precisão o status da requisição.


Como podemos perceber, esses quatro verbos nos permite traçar uma certa analogia entre os verbos HTTP e o SQL. Observando a tabela abaixo isto fica um pouco mais claro.


image2


Além dos verbos mencionados anteriormente temos outros menos usados.


HEAD – O verbo HEAD possui uma funcionalidade similar ao verbo GET, exceto pelo fato do servidor retornar uma response line e headers, mas sem um entity-body.
TRACE – O verbo TRACE é usado para recuperar o conteúdo de uma requisição HTTP de volta podendo ser usado com o propósito de debug durante o processo de desenvolvimento.
OPTIONS – O verbo OPTIONS é usado pelo cliente para encontrar operações HTTP e outras opções suportadas pelo servidor. O cliente pode especificar uma URL para o verbo OPTIONS ou um asterisco (*) para se referir a todo o servidor.
CONNECT – O verbo CONNECT é usado pelo cliente para estabelecer uma conexão de rede com um servidor via HTTP.
PATCH – O verbo PATCH pode ser usado para realizar updates parcias de um recurso. Por exemplo, quando você precisar alterar apenas um campo em um recurso, executar um POST com todo o objeto é pesado e acarreta em um maior consumo de banda. Levando isso em conta a primeira coisa que vem em mente é: “por que não usar o PATCH ao invés do PUT para realisar atualizações sempre?”. Simples o verbo PATCH pode ser um problema na medida em que não é idempotente. Além disso minimizar seu uso previne curupção de dados por “colisões” entre duas PATCH requests no mesmo recurso em um mesmo frame de tempo. Colisões entre multiplas PATCH requests são mais perigosas que colisõs entre PUT requests por que exige que o cliente tenha informações básicas do recurso ou irão corrompê-lo.


Formatos Suportados em Web Services RESTful


● XML
● JSON
● CSV
● Texto
● Imagens
● HTML
● PDF
● binário
● etc


Vantagens dos Web Services RESTful


REST é um padrão arquitetural basicamente leve por natureza. Então quando você tiver limitações de banda prefira web services REST;
● Desenvolvimento fácil e rápido;
● Grandes sites como Twitter, Yahoo, Google, Facebook usam este padrão.
● Aplicativos Mobile tem ganhado cada vez mais espaço e precisam interagir rapidamente com os servidores e o padrão REST é mais rápido no processamento de dados das requests e responses.


Botando em prática


Em breve estarão disponíveis dois posts Criando o primeiro endpoint REST com SpringBoot e Documentando aplicações RESTfull com SpringBoot e Swagger com exemplos práticos.


Referências


Apache CXF
JBoss RestEasy
Jersey
Redhat
Elkstein
DZone
REST API Tutorial
The RESTful CookBook
Tutorials Point

Tags: , , , ,

Web Services

Nos últimos meses me pediram a definição de Web-services em 3 processos seletivos diferentes, por mais simples que possa parecer definir conceitualmente pode ser mais complexo do que parece, sendo assim decidi fazer uma série de posts a respeito. Neles iremos aprender sobre os diferentes tipos de Web Services – ou simplesmente serviços. Pra começo de conversa um Serviço nada mais é que uma aplicação interoperável hospedada e acessada através da web através do protocolo HTTP por meio de um browser ou de diferentes tipos de clientes, como outras aplicações ou serviços. Deixando um pouco mais claro quando você cria um website em PHP a saída padrão é HTML e seu alvo é o browser e por extensão nós podemos visualizar a página no browser. Um web service não é direcionado para humanos e sim para outros programas.
O World Wide Web Consortium (W3C) define os web services como: aplicações cliente servidor que se comunicam pela World Wide Web’s (WWW) através do protocolo HTTP (HyperText Transfer Protocol) possibilitando a interoperabilidade entre softwares e aplicações executando em uma grande variedade de plataformas e frameworks. Caracterizam-se por sua grande interoperabilidade e extensibilidade podendo ser combinados de forma baixamente acoplada para executarem operações complexas. Programas proveem simples serviços que podem interagir uns com os outros gerando soluções sofisticadas.

Os serviços podem ser divididos em 2 grupos mais comumente conhecidos e usados, são eles:
eles:


REST (Representational State Transfer)


SOAP (Simple Object Access Protocol)


REST


JAX-RS 2.0 especificação que suporta a implementação para os serviços baseados RESTful no mundo Java.
● As principais implementações disponíveis para essa essa especificação são: Apache CXF, Spring MVC, JBoss RestEasy, Oracle Jersey (2.x) e Glassfish Jersey (2.x).


SOAP


JAX-WS 2.0 especificação que suporta a implementação para os serviços baseados em SOAP no mundo Java.
● As principais implementações disponíveis para essa essa especificação são: Apache CXF, JAX-WS, Apache Axis2 e Oracle WebLogic.


O diagrama abaixo representa bem essa “divisão” entre os 2 principais tipos de serviços.


image1


Nos próximos posts entraremos em maiores detalhes sobre a sopa de letrinhas REST, SOAP, SOA, API etc. Além disso iremos botar a mão na massa e codar um pouco.


Referências:


https://docs.oracle.com/javaee/6/tutorial/doc/gijvh.html

http://www.w3schools.com/webservices/ws_intro.asp

http://www.tutorialspoint.com/webservices/what_are_web_services.htm

http://stackoverflow.com/questions/226108/what-is-a-web-service-in-plain-english

Tags: , , , ,

Verificação de data online via web-services usando XStream.

O objetivo desse post é oferecer dicas de como trabalhar com web-services usando as bibliotecas XStream e HttpClient 4.x, que já abordamos em um post anterior, e além disso verificar a data corrente online. As vezes pode ser necessário verificar de tempos em tempos se a data de uma aplicação cliente é exatamente a mesma de uma aplicação servidora. Não é algo tão corriqueiro, entretanto tem uma importância razoável visto que uma bateria de BIOS ruim ou um usuário mal intencionado ou por erro podem alterar a data da máquina. Dentre as várias soluções para verificar essa data a mais lógica é verificar essa data online. Verificar a data na aplicação servidora não é muito interessante pois o cliente pode, ocasionalmente, perder a comunicação com a aplicação servidora. Diante disso a saída é consumir algum web-service que disponibilize essas informações. Como era de se esperar não encontrei um no Brasil (mesmo que existisse provavelmente seria pago como é o caso do CEP). Dos vários web-services internacionais o mais interessante, par esse propósito, é o disponibilizado pelo Earth Tools.org. Ele oferece uma série de informações sobre clima e outras coisas e claro também sobre data.

Partindo para o desenvolvimento a primeira coisa que precisamos é definir as dependências no nosso POM. As dependências mais importantes de nosso projeto são as do HttpClient e a XStream. As primeiras são necessárias para podermos nos comunicar com o web-service já a segunda converte XML em objetos Java.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 
    <!-- VERIFIQUE O POM COMPLETO NO GITHUB https://github.com/leandrocgsi/DateSynchronizer -->
 
    <dependencies>
 
        <!-- DEPENDÊNCIA DA XSTREAM RESPONSÁVEL POR CONVERTER XML EM OBJETOS -->
        <dependency>
            <groupId>com.thoughtworks.xstream</groupId>
            <artifactId>xstream</artifactId>
            <version>1.4.3</version>
        </dependency>
             
        <!-- DEPENDÊNCIA DA JERSEY -->
        <dependency>
            <groupId>com.sun.jersey</groupId>
            <artifactId>jersey-server</artifactId>
            <version>1.8</version>
        </dependency>
        
        <!-- DEPENDÊNCIA DO ASM --> 
        <dependency>
            <artifactId>asm</artifactId>
            <groupId>asm</groupId>
            <type>jar</type>
            <version>3.1</version>
        </dependency>
         
        <!-- DEPENDÊNCIA DO HTTP CLIENT -->
        <dependency>
            <groupId>org.apache.httpcomponents</groupId>
            <artifactId>httpclient</artifactId>
            <version>4.0.3</version>
        </dependency>
          
        <!-- DEPENDÊNCIA DO HTTP MIME -->   
        <dependency>
            <groupId>org.apache.httpcomponents</groupId>
            <artifactId>httpmime</artifactId>
            <version>4.0.3</version>
        </dependency>
         
        <!-- DEPENDÊNCIA DO HTTP CORE -->
        <dependency>
            <groupId>org.apache.httpcomponents</groupId>
            <artifactId>httpcore</artifactId>
            <version>4.0.1</version>
        </dependency>
             
        <!-- DEPENDÊNCIA DA JMONKEYENGINE-->
        <dependency>
            <groupId>com.projectdarkstar.ext.com.jmonkeyengine</groupId>
            <artifactId>jme-xml</artifactId>
            <version>2.0-S1</version>
            <type>jar</type>
        </dependency>
    </dependencies>
</project>

Agora partindo para as classes Java precisamos acessar a seguinte URL http://www.earthtools.org/timezone/-18.5134/-46.512809 que recebe como parâmetro em sua parte final dois números correspondentes a longitude e latitude de onde estamos acessando. Se acessarmos essa URL via browser veremos um XML similar ao da imagem abaixo.

Estrutura do XML

Podemos identificar, no XML, a necessidade de criarmos dois beans responsáveis por armazenar as informações do XML. O primeiro deles assinalado com o numero 1 (timezone) dará origem ao bean Timezone, que além de uma série de atributos simples possui um atributo composto por outro objeto (location) que por sua vez dará origem ao bean Location. Na criação do bean ao adicionarmos a anotação @XStreamAlias indicamos que aquele objeto representa um nó do arquivo XML. Fora isso nossas classes não possuem nada demais apenas geters, setters, serialização e construtor.

package br.com.semeru.datesynchronizer.beans;

import com.thoughtworks.xstream.annotations.XStreamAlias;
import java.io.Serializable;

// Anotação que indica para a XStream que timezone
// é um nó de um arquivo XML ou seja ele é um objeto
@XStreamAlias("timezone")
public class Timezone implements Serializable{

    //Atributo para serialização do bean
    private static final long serialVersionUID = 1L;
    
    //Atributo do XML
    private String version;

    /*Essa anotação indica que o atributo XML abaixo 
    é um atributo um pouco mais complexo e representa
    um objeto dentro de timezone*/
    @XStreamAlias("location")
    private Location location;
    
    //Outro atributo do XML
    private String offset;
    private String suffix;
    private String localtime;
    private String isotime;
    private String utctime;
    private String dst;

    // Construtor, getters e setters omitidos
        
}

Observe que o bean Timezone se relaciona de 1 para 1 com Location.

package br.com.semeru.datesynchronizer.beans;

import com.thoughtworks.xstream.annotations.XStreamAlias;
import java.io.Serializable;

/* Anotação que indica para a XStream que location
é um nó de um arquivo XML ou seja ele é um objeto */
@XStreamAlias("location")
public class Location implements Serializable{
    
    private static final long serialVersionUID = 1L;
    
    private String latitude;
    private String longitude;

    // Construtor, getters e setters omitidos
        
}

Feito isto é só nos acessarmos a URL e converter o XML em objetos. Inicialmente definimos a URL e um main que invoca um outro método (readXMLURL) que por sua vez se conecta à URL e recupera um inputStream que por sua vez é passado como parâmetro na invocação do método parserXMLToObject que recupera o XML do inputStream e converte-o em objeto retornando um objeto do tipo Timezone que agora podemos usar na aplicação.

package br.com.semeru.datesynchronizer;

import br.com.semeru.datesynchronizer.beans.Timezone;
import com.thoughtworks.xstream.XStream;
import com.thoughtworks.xstream.io.xml.DomDriver;
import java.io.IOException;
import java.io.InputStream;
import org.apache.http.HttpResponse;
import org.apache.http.HttpStatus;
import org.apache.http.client.HttpClient;
import org.apache.http.client.methods.HttpGet;
import org.apache.http.impl.client.DefaultHttpClient;

public class RecoveryDateWitchURL {

    //Determino a URL de onde será recuperada a informação do webservice
    private static String url = "http://www.earthtools.org/timezone/-18.5134/-46.512809";
        
    //Método main
    public static void main(String[] args) throws IOException, ClassNotFoundException {
        
        //Invoco o método passando como parâmetro a URL
        readXMLURL(url);
    }

    // Método responsável por recuperar um inputstream a
    // partir de uma URL e converter o resultado em objeto
    private static void readXMLURL(String url) throws IOException {
        
        //Crio uma instancia de cliente HTTP
        HttpClient client = new DefaultHttpClient();
        
        //Crio uma instancia de HTTPGet passando a URL como parâmetro
        HttpGet method = new HttpGet(url);
        
        //Atribuo à HTTP response o resutado da execução do método get
        HttpResponse httpResponse = client.execute(method);
        
        //Declaro uma variável que recebe o código de status da requisição HTTP
        int statusCode = httpResponse.getStatusLine().getStatusCode();
        
        //Verifico se o código do status é igual a SC_OK (200)
        if (statusCode == HttpStatus.SC_OK) {
            
            //Se for significa que a requisição foi bem sucedida e então
            //crio uma instancia de InputStream pegando o conteúdo da response
            InputStream inputStream = httpResponse.getEntity().getContent();
            
            //Invoco o método parserXMLToObject passando o inputStream como parâmetro
            parserXMLToObject(inputStream);
        }
    }
    
    //Método que efetivmente converte o input stream em XML e depois em objeto
    private static Timezone parserXMLToObject(InputStream inputStream) {
        
        //Crio uma instancia de XStream que recebe via
        //construtor uma instancia de DomDriver
        XStream xStream = new XStream(new DomDriver());
        
        //Processa as anotações da classe Timezone
        xStream.processAnnotations(Timezone.class);
        
        //Crio uma instancia de Timezone que recebe um cast para Timezone 
        //do inputstream convertido para XML e depois para Objetc
        Timezone timezone = (Timezone) xStream.fromXML(inputStream);
        
        //Imprimo algumas informações de timezone para testar
        System.out.println("O TimeZone É: " + timezone.getLocaltime() + " - " + timezone.getUtctime() + "\n"
                + "e as Cordenadas são: " + timezone.getLocation().getLatitude() + " de Latitude Sul" + timezone.getLocation().getLongitude() + " de Longitude Oeste. :-&gt;");
        
        //Retorno um objeto do tipo Timezone que poderá
        //ser usado em outras partes da aplicação.
        return timezone;
    }

}

Posteriormente pretendo fazer mais posts abordando outros aspectos de web-services. Lembrando sempre que se você ficou alguma dúvida relacionada ao conteúdo desse post sinta-se a vontade para comentar, criticar e/ou contribuir com o seu comentário. Além disso você pode acessar todo o código fonte desse projeto através do GitHub.

Tags: , , , ,