SlideShare ist ein Scribd-Unternehmen logo
1 von 12
Downloaden Sie, um offline zu lesen
Professor:Vinícius de Paula
Aluno:Tiago da Silva Lima
Disciplina: Programação de Sistemas Distribuídos e Concorrência
 Ambos possuem vantagens e desvantagens e
fica a cargo do desenvolvedor determinar a
melhor abordagem para cada caso em
particular.
SOAP (Simple Object Access Protocol, em português
Protocolo Simples de Acesso a Objetos) é um protocolo
para troca de informações estruturadas em uma plataforma
descentralizada e distribuída. Ele se baseia na Linguagem
de Marcação Extensível (XML) para seu formato de
mensagem, e normalmente baseia-se em outros protocolos
da Camada de aplicação, mais notavelmente em Chamada
de Procedimento Remoto (RPC) e Protocolo de
Transferência de Hipertexto (HTTP), para negociação e
transmissão de mensagens.
 ATransferência de Estado Representativo
(Representational StateTransfer) ou somente (REST) é
uma técnica de engenharia de software para sistemas
hipermídia distribuídos como aWorldWide Web. O termo
se originou no ano de 2000, em uma tese de doutorado
(PHD) sobre a web escrita por Roy Fielding, um dos
principais autores da especificação do protocolo HTTP que
é utilizado por sites da internet.
 O REST é simples de entender e pode ser
adotado em praticamente qualquer cliente ou
servidor com suporte a HTTP/HTTPS.
 Suas principais vantagens são a facilidade no
desenvolvimento, o aproveitamento da infra-
estrutura web existente e um esforço de
aprendizado pequeno.
 O SOAP, avô das interfaces de serviços web,
não deixará de ser usado tão cedo.
 Com o SOAP v 1.2, muitas das deficiências
percebidas nessa tecnologia foram corrigidas
e aumentou a facilidade de uso.
 Utilizar o SOAP 1.2 traz uma carga adicional
não encontrada ao usar REST, mas há
também vantagens.
 É mais elegante, pois utiliza ao máximo o protocolo HTTP,
evitando a construção de protocolos adicionais;
 Tem o potencial de ser bem mais simples que uma
implementação com WSDL/SOAP;
 Tende a ser mais performático;
 ~ 80% das integrações utilizam o protocolo HTTP;
 A possibilidade de ter diversas representações de um
mesmo recurso, por exemplo, uma dada entidade pode
ser representada em diferentes formatos como Json, xml,
html e text/plain, dependendo da requisição feita pelo
cliente(Content-Negotiation)
 Possibilidade de navegar entre relacionamentos (Links
web) de vários recursos de forma dinamica. seguindo a
usabilidade de qualquer sistema web.
 É um padrão que combinado a especificaçõesWS-*
podem garantir questões deQoS(Quality of Service),
Segurança, transação e outras questões presentes em
integrações mais complexas.
 Uma mensagem SOAP pode ser propagada por
diferentes protocolos, o que flexibiliza bastante várias
integrações.
 É um padrão que está muito maduro no mercado,
qualquer ferramenta de integração e Framework tem
várias funcionalidades para manipular as mensagens
que seguem este padrão.
 Mas uma história não contada é que ambas
as tecnologias podem ser misturadas e
combinadas. O REST é fácil de entender e
extremamente acessível porém faltam
padrões, e a tecnologia é considerada apenas
uma abordagem arquitetural.
 Em comparação, o SOAP é um padrão da
indústria, com protocolos bem definidos e
um conjunto de regras bem estabelecidas.
 Situações em que há limitação de recursos e de largura de banda:
A estrutura de retorno é em qualquer formato definido pelo
desenvolvedor e qualquer navegador pode ser usado. Isso porque
a abordagem REST usa o padrão de chamadas GET, PUT, POST e
DELETE. O REST também pode usar objetosXMLHttpRequest (a
base do velho AJAX) que a maioria dos navegadores modernos
suporta.
 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.
 Situações que exigem cache: se a informação pode ser
armazenada em cache, devido à natureza da operação stateless
do REST, esse seria um cenário adequado para a tecnologia.
 Processamento e chamada assíncronos: se o aplicativo precisa de
um nível garantido de confiabilidade e segurança para a troca de
mensagens, então o SOAP 1.2 oferece padrões adicionais para
esse tipo de operação como por exemplo oWSRM (WS-Reliable
Messaging).
 Contratos formais: se ambos os lados (fornecedor e consumidor)
têm que concordar com o formato de intercâmbio de dados, então
o SOAP 1.2 fornece especificações rígidas para esse tipo de
interação.
 Operações stateful: para o caso de o aplicativo precisar de
informação contextual e gerenciamento de estado com
coordenação e segurança, o SOAP 1.2 possui uma especificação
adicional em sua estrutura que apoia essa necessidade (segurança,
transações, coordenação etc.). Comparativamente, usar o REST
exigiria que os desenvolvedores construíssem uma solução
personalizada.
 Como se vê, cada uma das abordagens tem
sua utilidade.Ambas têm problemas nos
quesitos de segurança, camadas de
transporte etc.; mas ambas podem realizar o
trabalho necessário e trazem sua
contribuição para o desenvolvimento de
aplicações web.
 Portanto, a melhor abordagem é a
flexibilidade.

Weitere ähnliche Inhalte

Was ist angesagt?

HTTP request and response
HTTP request and responseHTTP request and response
HTTP request and responseSahil Agarwal
 
Developing a test automation strategy by Brian Bayer
Developing a test automation strategy by Brian BayerDeveloping a test automation strategy by Brian Bayer
Developing a test automation strategy by Brian BayerQA or the Highway
 
Understanding Database Transactions and Hibernate Sessions in Grails
Understanding Database Transactions and Hibernate Sessions in GrailsUnderstanding Database Transactions and Hibernate Sessions in Grails
Understanding Database Transactions and Hibernate Sessions in GrailsJonas Witt
 
Introduction to WebSockets Presentation
Introduction to WebSockets PresentationIntroduction to WebSockets Presentation
Introduction to WebSockets PresentationJulien LaPointe
 
ASP.NET Web API and HTTP Fundamentals
ASP.NET Web API and HTTP FundamentalsASP.NET Web API and HTTP Fundamentals
ASP.NET Web API and HTTP FundamentalsIdo Flatow
 
An Overview of Web Services: SOAP and REST
An Overview of Web Services: SOAP and REST An Overview of Web Services: SOAP and REST
An Overview of Web Services: SOAP and REST Ram Awadh Prasad, PMP
 
Learn REST in 18 Slides
Learn REST in 18 SlidesLearn REST in 18 Slides
Learn REST in 18 SlidesSuraj Gupta
 
Repository and Unit Of Work Design Patterns
Repository and Unit Of Work Design PatternsRepository and Unit Of Work Design Patterns
Repository and Unit Of Work Design PatternsHatim Hakeel
 
Soap and restful webservice
Soap and restful webserviceSoap and restful webservice
Soap and restful webserviceDong Ngoc
 
From ddd to DDD : My journey from data-driven development to Domain-Driven De...
From ddd to DDD : My journey from data-driven development to Domain-Driven De...From ddd to DDD : My journey from data-driven development to Domain-Driven De...
From ddd to DDD : My journey from data-driven development to Domain-Driven De...Thibaud Desodt
 
Lezione 8: Introduzione ai Web Service
Lezione 8: Introduzione ai Web ServiceLezione 8: Introduzione ai Web Service
Lezione 8: Introduzione ai Web ServiceAndrea Della Corte
 
O básico do uso de rest vs soap
O básico do uso de rest vs soapO básico do uso de rest vs soap
O básico do uso de rest vs soapJeison Barros
 
Programmation réactive avec Spring 5 et Reactor
Programmation réactive avec Spring 5 et ReactorProgrammation réactive avec Spring 5 et Reactor
Programmation réactive avec Spring 5 et ReactorFlorian Beaufumé
 

Was ist angesagt? (20)

WSDL
WSDLWSDL
WSDL
 
HTTP request and response
HTTP request and responseHTTP request and response
HTTP request and response
 
Developing a test automation strategy by Brian Bayer
Developing a test automation strategy by Brian BayerDeveloping a test automation strategy by Brian Bayer
Developing a test automation strategy by Brian Bayer
 
Understanding Database Transactions and Hibernate Sessions in Grails
Understanding Database Transactions and Hibernate Sessions in GrailsUnderstanding Database Transactions and Hibernate Sessions in Grails
Understanding Database Transactions and Hibernate Sessions in Grails
 
Introduction to WebSockets Presentation
Introduction to WebSockets PresentationIntroduction to WebSockets Presentation
Introduction to WebSockets Presentation
 
ASP.NET Web API and HTTP Fundamentals
ASP.NET Web API and HTTP FundamentalsASP.NET Web API and HTTP Fundamentals
ASP.NET Web API and HTTP Fundamentals
 
An Overview of Web Services: SOAP and REST
An Overview of Web Services: SOAP and REST An Overview of Web Services: SOAP and REST
An Overview of Web Services: SOAP and REST
 
Mediator Design Pattern
Mediator Design PatternMediator Design Pattern
Mediator Design Pattern
 
Learn REST in 18 Slides
Learn REST in 18 SlidesLearn REST in 18 Slides
Learn REST in 18 Slides
 
Webdriver.io
Webdriver.io Webdriver.io
Webdriver.io
 
Repository and Unit Of Work Design Patterns
Repository and Unit Of Work Design PatternsRepository and Unit Of Work Design Patterns
Repository and Unit Of Work Design Patterns
 
Codeigniter
CodeigniterCodeigniter
Codeigniter
 
RESTful Web Services
RESTful Web ServicesRESTful Web Services
RESTful Web Services
 
Soap and restful webservice
Soap and restful webserviceSoap and restful webservice
Soap and restful webservice
 
Rest API
Rest APIRest API
Rest API
 
From ddd to DDD : My journey from data-driven development to Domain-Driven De...
From ddd to DDD : My journey from data-driven development to Domain-Driven De...From ddd to DDD : My journey from data-driven development to Domain-Driven De...
From ddd to DDD : My journey from data-driven development to Domain-Driven De...
 
Lezione 8: Introduzione ai Web Service
Lezione 8: Introduzione ai Web ServiceLezione 8: Introduzione ai Web Service
Lezione 8: Introduzione ai Web Service
 
An Introduction To REST API
An Introduction To REST APIAn Introduction To REST API
An Introduction To REST API
 
O básico do uso de rest vs soap
O básico do uso de rest vs soapO básico do uso de rest vs soap
O básico do uso de rest vs soap
 
Programmation réactive avec Spring 5 et Reactor
Programmation réactive avec Spring 5 et ReactorProgrammation réactive avec Spring 5 et Reactor
Programmation réactive avec Spring 5 et Reactor
 

Andere mochten auch

Andere mochten auch (6)

Arquitetura SOAP e REST
Arquitetura SOAP e RESTArquitetura SOAP e REST
Arquitetura SOAP e REST
 
Web Services Rest
Web Services RestWeb Services Rest
Web Services Rest
 
WebServices intro
WebServices introWebServices intro
WebServices intro
 
No mundo das ap is com Restful webservices
No mundo das ap is com Restful webservicesNo mundo das ap is com Restful webservices
No mundo das ap is com Restful webservices
 
Aula 2 introdução a sistemas distribuídos
Aula 2   introdução a sistemas distribuídosAula 2   introdução a sistemas distribuídos
Aula 2 introdução a sistemas distribuídos
 
Web Services PHP Tutorial
Web Services PHP TutorialWeb Services PHP Tutorial
Web Services PHP Tutorial
 

Ähnlich wie Diferenças entre SOAP e REST

Psdc - 2014/01
Psdc - 2014/01Psdc - 2014/01
Psdc - 2014/01Isa Prati
 
04 - Felipe Oliveira - Think Decoupled! (SOA)
04 - Felipe Oliveira - Think Decoupled! (SOA)04 - Felipe Oliveira - Think Decoupled! (SOA)
04 - Felipe Oliveira - Think Decoupled! (SOA)DNAD
 
Webservices e Xml
Webservices e XmlWebservices e Xml
Webservices e Xmlsys10
 
Soa – Woa Rest Arquiteturas
Soa – Woa   Rest ArquiteturasSoa – Woa   Rest Arquiteturas
Soa – Woa Rest Arquiteturasrafaslide
 
Web Services Xml
Web Services XmlWeb Services Xml
Web Services XmlUFMG
 
Arquitetura de Serviços - SOA, REST, Microservices e a plataforma .NET
Arquitetura de Serviços - SOA, REST, Microservices e a plataforma .NETArquitetura de Serviços - SOA, REST, Microservices e a plataforma .NET
Arquitetura de Serviços - SOA, REST, Microservices e a plataforma .NETRenato Groff
 
Arquitetura de Serviços - SOA, REST, Microservices e a plataforma .NET
Arquitetura de Serviços - SOA, REST, Microservices e a plataforma .NETArquitetura de Serviços - SOA, REST, Microservices e a plataforma .NET
Arquitetura de Serviços - SOA, REST, Microservices e a plataforma .NETRenato Groff
 
Sistemas Distribuídos - Big Web Services
Sistemas Distribuídos - Big Web ServicesSistemas Distribuídos - Big Web Services
Sistemas Distribuídos - Big Web ServicesKeyo Galvao
 
[Ass] arquiteturas soa, woa, e rest
[Ass] arquiteturas soa, woa, e rest[Ass] arquiteturas soa, woa, e rest
[Ass] arquiteturas soa, woa, e restassufmg
 

Ähnlich wie Diferenças entre SOAP e REST (20)

Psdc - 2014/01
Psdc - 2014/01Psdc - 2014/01
Psdc - 2014/01
 
Android + web service
Android + web serviceAndroid + web service
Android + web service
 
Soap x rest
Soap x restSoap x rest
Soap x rest
 
Rest e soap
Rest e soapRest e soap
Rest e soap
 
Trabalho Final PSDC - Simião
Trabalho Final PSDC - SimiãoTrabalho Final PSDC - Simião
Trabalho Final PSDC - Simião
 
Palestra Sobre REST
Palestra Sobre RESTPalestra Sobre REST
Palestra Sobre REST
 
SOAP e REST
SOAP e RESTSOAP e REST
SOAP e REST
 
04 - Felipe Oliveira - Think Decoupled! (SOA)
04 - Felipe Oliveira - Think Decoupled! (SOA)04 - Felipe Oliveira - Think Decoupled! (SOA)
04 - Felipe Oliveira - Think Decoupled! (SOA)
 
WebServices-XML
WebServices-XMLWebServices-XML
WebServices-XML
 
Trabalho final psdc
Trabalho final psdcTrabalho final psdc
Trabalho final psdc
 
Web service
Web serviceWeb service
Web service
 
Webservices e Xml
Webservices e XmlWebservices e Xml
Webservices e Xml
 
Soa – Woa Rest Arquiteturas
Soa – Woa   Rest ArquiteturasSoa – Woa   Rest Arquiteturas
Soa – Woa Rest Arquiteturas
 
Web services
Web servicesWeb services
Web services
 
Web Services Xml
Web Services XmlWeb Services Xml
Web Services Xml
 
Arquitetura de Serviços - SOA, REST, Microservices e a plataforma .NET
Arquitetura de Serviços - SOA, REST, Microservices e a plataforma .NETArquitetura de Serviços - SOA, REST, Microservices e a plataforma .NET
Arquitetura de Serviços - SOA, REST, Microservices e a plataforma .NET
 
Arquitetura de Serviços - SOA, REST, Microservices e a plataforma .NET
Arquitetura de Serviços - SOA, REST, Microservices e a plataforma .NETArquitetura de Serviços - SOA, REST, Microservices e a plataforma .NET
Arquitetura de Serviços - SOA, REST, Microservices e a plataforma .NET
 
Web Service - XML
Web Service - XMLWeb Service - XML
Web Service - XML
 
Sistemas Distribuídos - Big Web Services
Sistemas Distribuídos - Big Web ServicesSistemas Distribuídos - Big Web Services
Sistemas Distribuídos - Big Web Services
 
[Ass] arquiteturas soa, woa, e rest
[Ass] arquiteturas soa, woa, e rest[Ass] arquiteturas soa, woa, e rest
[Ass] arquiteturas soa, woa, e rest
 

Diferenças entre SOAP e REST

  • 1. Professor:Vinícius de Paula Aluno:Tiago da Silva Lima Disciplina: Programação de Sistemas Distribuídos e Concorrência
  • 2.  Ambos possuem vantagens e desvantagens e fica a cargo do desenvolvedor determinar a melhor abordagem para cada caso em particular.
  • 3. SOAP (Simple Object Access Protocol, em português Protocolo Simples de Acesso a Objetos) é um protocolo para troca de informações estruturadas em uma plataforma descentralizada e distribuída. Ele se baseia na Linguagem de Marcação Extensível (XML) para seu formato de mensagem, e normalmente baseia-se em outros protocolos da Camada de aplicação, mais notavelmente em Chamada de Procedimento Remoto (RPC) e Protocolo de Transferência de Hipertexto (HTTP), para negociação e transmissão de mensagens.
  • 4.  ATransferência de Estado Representativo (Representational StateTransfer) ou somente (REST) é uma técnica de engenharia de software para sistemas hipermídia distribuídos como aWorldWide Web. O termo se originou no ano de 2000, em uma tese de doutorado (PHD) sobre a web escrita por Roy Fielding, um dos principais autores da especificação do protocolo HTTP que é utilizado por sites da internet.
  • 5.  O REST é simples de entender e pode ser adotado em praticamente qualquer cliente ou servidor com suporte a HTTP/HTTPS.  Suas principais vantagens são a facilidade no desenvolvimento, o aproveitamento da infra- estrutura web existente e um esforço de aprendizado pequeno.
  • 6.  O SOAP, avô das interfaces de serviços web, não deixará de ser usado tão cedo.  Com o SOAP v 1.2, muitas das deficiências percebidas nessa tecnologia foram corrigidas e aumentou a facilidade de uso.  Utilizar o SOAP 1.2 traz uma carga adicional não encontrada ao usar REST, mas há também vantagens.
  • 7.  É mais elegante, pois utiliza ao máximo o protocolo HTTP, evitando a construção de protocolos adicionais;  Tem o potencial de ser bem mais simples que uma implementação com WSDL/SOAP;  Tende a ser mais performático;  ~ 80% das integrações utilizam o protocolo HTTP;  A possibilidade de ter diversas representações de um mesmo recurso, por exemplo, uma dada entidade pode ser representada em diferentes formatos como Json, xml, html e text/plain, dependendo da requisição feita pelo cliente(Content-Negotiation)  Possibilidade de navegar entre relacionamentos (Links web) de vários recursos de forma dinamica. seguindo a usabilidade de qualquer sistema web.
  • 8.  É um padrão que combinado a especificaçõesWS-* podem garantir questões deQoS(Quality of Service), Segurança, transação e outras questões presentes em integrações mais complexas.  Uma mensagem SOAP pode ser propagada por diferentes protocolos, o que flexibiliza bastante várias integrações.  É um padrão que está muito maduro no mercado, qualquer ferramenta de integração e Framework tem várias funcionalidades para manipular as mensagens que seguem este padrão.
  • 9.  Mas uma história não contada é que ambas as tecnologias podem ser misturadas e combinadas. O REST é fácil de entender e extremamente acessível porém faltam padrões, e a tecnologia é considerada apenas uma abordagem arquitetural.  Em comparação, o SOAP é um padrão da indústria, com protocolos bem definidos e um conjunto de regras bem estabelecidas.
  • 10.  Situações em que há limitação de recursos e de largura de banda: A estrutura de retorno é em qualquer formato definido pelo desenvolvedor e qualquer navegador pode ser usado. Isso porque a abordagem REST usa o padrão de chamadas GET, PUT, POST e DELETE. O REST também pode usar objetosXMLHttpRequest (a base do velho AJAX) que a maioria dos navegadores modernos suporta.  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.  Situações que exigem cache: se a informação pode ser armazenada em cache, devido à natureza da operação stateless do REST, esse seria um cenário adequado para a tecnologia.
  • 11.  Processamento e chamada assíncronos: se o aplicativo precisa de um nível garantido de confiabilidade e segurança para a troca de mensagens, então o SOAP 1.2 oferece padrões adicionais para esse tipo de operação como por exemplo oWSRM (WS-Reliable Messaging).  Contratos formais: se ambos os lados (fornecedor e consumidor) têm que concordar com o formato de intercâmbio de dados, então o SOAP 1.2 fornece especificações rígidas para esse tipo de interação.  Operações stateful: para o caso de o aplicativo precisar de informação contextual e gerenciamento de estado com coordenação e segurança, o SOAP 1.2 possui uma especificação adicional em sua estrutura que apoia essa necessidade (segurança, transações, coordenação etc.). Comparativamente, usar o REST exigiria que os desenvolvedores construíssem uma solução personalizada.
  • 12.  Como se vê, cada uma das abordagens tem sua utilidade.Ambas têm problemas nos quesitos de segurança, camadas de transporte etc.; mas ambas podem realizar o trabalho necessário e trazem sua contribuição para o desenvolvimento de aplicações web.  Portanto, a melhor abordagem é a flexibilidade.