Juliana Jenny Kolb
Home > Simulados on-line > Questões de Concursos > Tecnologia da Informação (TI) > Web Service
Web Service REST
REST é outro um protocolo de comunicação, baseado no protocolo de hipermídia HTTP. Porém ele não impõe restrições ao formato da mensagem, apenas no comportamento dos componentes envolvidos.
A maior vantagem do protocolo REST é sua flexibilidade. O desenvolvedor pode optar pelo formato mais adequado para as mensagens do sistema de acordo com sua necessidade específica. Os formatos mais comuns são JSON, XML e texto puro, mas em teoria qualquer formato pode ser usado.
Isso nos leva a outra vantagem: quase sempre Web Services que usam REST são mais “leves” e, portanto, mais rápidos.
O problema com o REST pode surgir justamente por causa de suas vantagens. Como a definição do corpo de dados fica totalmente a cargo do desenvolvedor, os problemas de interoperabilidade são mais comuns.
Componentes REST
- Recursos: identificação do caminho da reuisição Web, a URI (Unified Resource Identifier), ou seja, o identificador único de um recurso.
- Operações: o protocolo HTTP possui sete operações, os métodos:
- GET – recupera informações sobre o recurso identificado pela URI. Ex: listar produtos, visualizar o produto 45. Uma requisição GET não deve modificar nenhum recurso do seu sistema, ou seja, não deve ter nenhum efeito colateral, você apenas recupera informações do sistema.
- POST – adiciona informações usando o recurso da URI passada. Ex: adicionar um produto. Pode adicionar informações a um recurso ou criar um novo recurso.
- PUT – adiciona (ou modifica) um recurso na URI passada. Ex: atualizar um produto. A diferença fundamental entre um PUT e um POST é que no POST a URI significa o lugar que vai tratar a informação, e no PUT significa o lugar em que a informação será armazenada.
- DELETE – remove o recurso representado pela URI passada. Ex: remover um produto.
- HEAD, OPTIONS e TRACE – recuperam metadados da URI passada. Respectivamente o Header, quais métodos são possíveis e informações de debug.
- Representação: as URIs devem representar recursos, as operações no recurso devem ser indicadas pelos métodos HTTP e podemos falar qual é o formato em que conversamos com o servidor com o Content Type.
SOAP x REST (segundo https://pt.stackoverflow.com)
Em geral, SOAP é uma boa opção para instituições com padrões rígidos e ambientes complexos (várias plataformas e sistemas). Muitas ferramentas corporativas (como ESB) tiram vantagem do padrão e possibilitam filtrarem, enfileiramento, classificação e redirecionamento das mensagens trocadas entre sistemas.
No restante, para uso no dia-a-dia, não vejo motivos concretos para não usar REST e JSON. Praticamente todas as plataformas e linguagens modernas que conheço suportam esses conceitos e a solução final é muito mais simples do que o equivalente em SOAP.
Além disso, integrações com alto volume de requisições são inviáveis em SOAP. REST é capaz de atender volume e complexidade sem dificuldades, exigindo apenas um mínimo de experiência do desenvolvedor para estabelecer e reforçar os padrões adequados.
Site de Referência
https://pt.stackoverflow.com