<------ Abra uma nova discussão, clicando na Categoria desejada primeiramente. Fica mais fácil e organizado :-)

Artigo Rest vs SOAP

Artigo interessante na InfoQ comparando Rest vs SOAP.

Alguns erros conceituais, mas acredito que o mais importante foi a mensagem final:

http://www.infoq.com/br/articles/rest-soap-when-to-use-each

Vale à pena dar uma olhada e podemos comentar seus erros aqui.

Um abraço,

_________________
Felipe Oliveira
SOA|EXPERT
twitter :: @scaphe
·

Comentários

  • edited outubro 2013
    Gostei da maioria das comparações entre os dois no artigo, achei bem esclarecedoras. Um coisa que notei foi que ele citou REST como funcionando apenas com os protocolos HTTP/HTTPs. REST é um estilo arquitetural, podendo funcionar em qualquer protocolo que siga esse estilo, correto?

    Um outra coisa que vi foi:
    "Operações totalmente sem-estado: se uma operação precisa ser continuada, o REST não será a melhor opção. No entanto, se forem necessárias operações de CRUD stateless (Criar, Ler, Atualizar e Excluir), o REST seria a melhor alternativa."

    Com REST não se deve guardar estado no servidor entre operações, porém coreografia utilizando HATEOAS pode ser uma ótima alternativa para quando há necessidade de guardar estado (client).

    ·
  • Bem observado Ivan,

    Hateoas significa Hypermedia as the Engine of Application State, ou seja, máquina de estados coreografada, onde seu estado é mantido através da hypermedia no cliente.

    Rest não é expor somente os recursos através de um protocolo, outro erro também, pois poderia ser outro protocolo e não está atrelado ao HTTP somente.

    Fazer EntityServices é o terceiro erro, a granularidade ficaria muito fina e você comprometeria seu design.

    Os links do estilo arquitetural são basicamente 2: Links estruturais e de Ações. Os estruturais representam os recursos, como itens de um pedido e os links de ação fariam de fato o controle transacional.

    SOAP não é uma especificação de serviços e sim um protocolo e WS-Standards sim é a especificação. Entendemos que ele quis dizer o primeiro estilo, mas poderia trabalhar com WSDSL 2.0 somente com HTTP sem SOAP. Aliás, isso seria possível até mesmo com WSDL 1.0 embora faria menos sentido, pois não usaria corretamente os verbos do HTTP.

    Há outros conceitos como WS-Adressing que ele não citou, que fazem a correlação para mensagens assíncronas.

    Em resumo, o artigo dá uma boa clarificada para "odiadores" de WS da importância do mesmo, mas há muitos erros conceituais.

    _________________
    Felipe Oliveira
    SOA|EXPERT
    twitter :: @scaphe
    ·
  • Só de ele falar que http://www.minhaempresa.com.br/programa/metodo?Parametros=xx é um exemplo de chamada REST já me começou a doer a alma. Isso é RPC over HTTP.

    REST pode até ser um estilo arquitetural que não está atrelado a nenhum protocolo, mas o Roy Fielding foi muito específico que ele é um estilo para um sistema de hipermídia distribuído, e essa tese dele foi feita para explicar por quê o maior sistema distribuído do mundo, a Web, funciona. E a Web roda em cima de HTTP e HTTPS.

    Segundo, novamente, REST não é um sistema de Remote Procedure Call. Em RPCs você passa o nome da função/procedimento/método/subprograma, e os argumentos dessa chamada.
    Enquanto no RPC, o subprograma é o objeto principal do sistema, em REST o objeto é um recurso. Um recurso é um mapeamento conceitual para uma ou mais entidades ou valores do seu sistema.

    Aliás, apesar que o principal é o recurso, o cliente não trabalha com ele diretamente. Ele só tenta acessar ele através de um identificador desse recurso (URI), e recebe de volta uma representação desse recurso que ele entende.

    Por exemplo, se o Photoshop acessar um recurso de uma cadeira, ele receberia uma foto, o AutoCAD receberia um modelo 3D, uma impressora 3D já faria a cadaira para você. Um navegador de internet, que já entende N formatos, poderia negociar com o servidor para ele mandar uma foto, um modelo 3D para carregar num plugin flash, ou textos em formato html, xml, json, etc, descrevendo a cadeira.

    Essa história que REST funciona bem em largura de banda limitada depende mesmo é dessa negociação de conteúdo com o servidor. O cliente pode escolher uma representação com tamanho menor ou maior. Outra coisa a considerar, por essa natureza de manipular recursos estilo CRUD, é perigoso que o sistema se torne falativo demais, granularidade pequena, indo e vindo com requests, o que é ruim em clientes mobile.

    Enfim, acho que ele poderia ficar um tempo explicando recursos, negociação, media types, links, maquina de estado. Se o desenvolvedor achar que REST se resume a economizar banda e escalabilidade, vai ter uma bela surpresa na mudança de paradigma que ele precisa ter para implementar essa arquitetura.
    ·
  • edited outubro 2013
    Sobre HATEOAS, que considero o estilo de REST de verdade(palpável):

    http://jim.webber.name/downloads/presentations/2009-05-HATEOAS.pdf
    ·
Entre ou Registre-se para fazer um comentário.