[quote]
A Transferência do Estado Representacional é pretendida como uma imagem do design da aplicação se comportará: uma rede de websites (um estado virtual), onde o usuário progride com uma aplicação selecionando as ligações (transições do estado), tendo como resultado a página seguinte (que representa o estado seguinte da aplicação) que está sendo transferida ao usuário e apresentada para seu uso.[/quote]
Onde está a novidade disso?
Qual a diferença de um webservice ‘restful’ para webservices ‘normais’(SOAP,AXIS etc)?
Ora, mas a idéia é exatamente essa, de que não exista novidade nenhuma
Com REST a idéia não é que você tem serviços, mas que você tem recursos ( cada um identificado pela sua própria URI ) que podem sofrer operações através de uma interface comum do seu protocolo. Esses serviços fazem as vezes dos “serviços” do SOAP mas de uma forma diferente, em REST quando você acessa um recurso qualquer você está acessando uma das possíveis representações dele (ele não precisa ser um documento XML como em SOAP, por exemplo), ele pode ser um documento XHTML comum, um objeto no formato JSON ou qualquer outra coisa que você precise.
Imaginemos uma aplicação REST rodando em cima de HTTP que sirva pra buscar informações sobre o CEP como o WS de CEP dos correios. Diferentemente de SOAP, REST não ignora o protocolo sobre o qual ele está rodando, ele faz uso de tudo o que o protocolo oferece, então na hora de fazer a busca pelo nosso cep ( digamos “58075-300”)aconteceria o seguinte:
A aplicação rest dos correios busca por um cep (o recurso) que tenha como identificador o código “58075-300”, se ele encontrar, vai retornar para o cliente uma resposta HTTP 200 com o recurso cep (com rua, cidade, estado e blablabla) e além disso vai colocar os cabeçalhos HTTP “Last-Modified-At” e “Expires” (informações de CEP não mudam com frequência, então ele pode botar essa informação pra expirar daqui a um mês ou talvez até mesmo um ano)
O cliente recebe a resposta, guarda a representação no seu cache (como qualquer navegador web comum faria) e faz o que tinha que fazer com as informações do CEP
Se o cliente tentar pegar mais uma vez informações do mesmo cep, ele não vai mais ao site dos correios, ele vai direto pegar a representação que já está disponível no seu cache.
E como aplicações REST não guardam estado dos seus clientes (e essa roda em cima de HTTP, que é um protocolo sem estado por natureza) esse serviço pode ser facilmente espalhado em diversas máquinas.
o que eu não entendo é o seguinte:
1 - tudo que eu posso fazer com SOAP eu tambem posso fazer sem SOAP?
2 - se REST existe desde sempre,pq não é usado desde sempre(não no caso de WS)?
[quote=raf4ever]então,apenas nos casos citados(transação,orquestrações) SOAP é algo justificável?
Onde mais?[/quote]
Orquestrações e transações podem ser feitas com REST também
Agora mensageria assíncrona é uma coisa difícil de se fazer com REST em cima de HTTP. SOAP vai ter um dia “Reliable messaging”, então pode ser que ele venha a ser melhor que rest nesse caso, mas tudo deve ser avaliado caso a caso, não dá pa se assumir as coisas tão preto no branco assim sem conhecer a realidade do problema.
Então você faz o seguinte, tenta fazer com rest, se não der, parte pra SOAP
agora chegamos onde eu queria…
O problema é que tenho visto por ai o REST ser apontado como a “salvação da lavoura”,e quis saber se tudo que fiz e tenho feito
com SOAP era tão “1990” assim…
Mas REST é a salvação da lavoura pra 99% das necessidades (medido com o Istatistical Medidator Tabajara)
Falando sério, SOAP complica demais pra todos os casos, não existe simplicidade pro que é simples. REST é simples pra todos os casos, se você precisar de alguma coisa complexa demais e que seja difícil demais de se fazer com REST, é aí que você poderia partir pra SOAP.
Cara, desde que entendi como o REST funciona fico me perguntando quase que sempre em que cenário vou precisar de SOAP a não ser por imposição do cliente.
Pois é…
a coisa é tão “estupidamente” simples que tô me perguntando isso tambem :D[/quote]
Tem empresas e principalmente órgãos públicos que não aceitam algo simples, como justificar a aquisição de toneladas de tools a preços exorbitantes se é para usar com REST?
Só lembrando, REST é stateless, que no final das contas dá para simular no servidor
