{"id":38,"date":"2007-10-09T15:36:45","date_gmt":"2007-10-09T15:36:45","guid":{"rendered":"http:\/\/www.inospito.net\/?p=38"},"modified":"2018-03-09T15:46:37","modified_gmt":"2018-03-09T15:46:37","slug":"o-debate-soap-vs-rest","status":"publish","type":"post","link":"http:\/\/www.inospito.net\/2007\/10\/o-debate-soap-vs-rest\/","title":{"rendered":"O debate SOAP vs REST"},"content":{"rendered":"<p>Quem tenha lidado com\u00a0<a href=\"http:\/\/en.wikipedia.org\/wiki\/Web_service\">webservices<\/a>\u00a0nos \u00faltimos tempos, ou se deparou com o\u00a0debate SOAP vs REST, ou andou com a cabe\u00e7a enfiada na areia. Para quem andou com a cabe\u00e7a enfiada na areia, aqui vai um resumo pragm\u00e1tico:<\/p>\n<ul>\n<li>Um webservice \u00e9 uma maneira de uma\u00a0<strong>aplica\u00e7\u00e3o<\/strong>\u00a0comunicar com um servidor Web. Tradicionalmente, quem interage com um servidor web \u00e9 um\u00a0<strong>ser humano<\/strong>, atrav\u00e9s de um browser.\u00a0<strong>Se trocarmos o ser humano por uma aplica\u00e7\u00e3o, a interac\u00e7\u00e3o passa a ser por webservices<\/strong>.<\/li>\n<li>Podem-se implementar webservices de v\u00e1rias maneiras. Duas delas ganharam notoriedade, por diferentes raz\u00f5es:\u00a0<a href=\"http:\/\/www.w3.org\/TR\/soap\/\" target=\"_blank\" rel=\"noopener\">SOAP<\/a>\u00a0e\u00a0<a href=\"https:\/\/web.archive.org\/web\/20120327223626\/http:\/\/www.ics.uci.edu\/~fielding\/pubs\/dissertation\/top.htm\" target=\"_blank\" rel=\"noopener\">REST<\/a><\/li>\n<li>SOAP \u00e9 pegar numa mensagem xml, met\u00ea-la num envelope e envi\u00e1-la por HTTP (embora o SOAP permita diferentes protocolos de transporte, na pr\u00e1tica \u00e9 HTTP). A resposta vem igualmente num envelope, em xml. Apesar de utilizar HTTP, esque\u00e7am quaisquer mecanismos pr\u00e9-existentes na linguagem\/framework para comunicar em SOAP. Aquilo utiliza uns headers especiais, como tal precisam de uma biblioteca especializada.<\/li>\n<li>REST \u00e9 usar o HTTP como ele foi concebido, com GET, POST, PUT e DELETE (estes \u00faltimos dois quase n\u00e3o s\u00e3o utilizados mas est\u00e3o na especifica\u00e7\u00e3o desde o in\u00edcio). Ou seja, se sabem fazer submit de forms, sabem usar REST. A diferen\u00e7a \u00e9 que o submit de um form devolve uma p\u00e1gina em html, e um webservice REST devolve uma p\u00e1gina em xml.<\/li>\n<\/ul>\n<p>Feito o resumo, vamos directos para as conclus\u00f5es:<\/p>\n<ul>\n<li>O SOAP n\u00e3o foi desenhado para resolver um problema, mas sim para vender ferramentas, ou n\u00e3o estivessem\u00a0<em>big players<\/em>\u00a0como a\u00a0Microsoft\u00a0ou a\u00a0Oracle\u00a0envolvidos. Digo isto, porque ningu\u00e9m no seu perfeito ju\u00edzo implementa a comunica\u00e7\u00e3o SOAP \u00e0 m\u00e3o. Quem definiu o standard, garantiu que o formato era suficientemente cr\u00edptico e complexo para ser utiliz\u00e1vel apenas recorrendo a bibliotecas\/ferramentas de terceiros (muitas delas pagas, est\u00e1 claro). Teoricamente a ideia \u00e9 boa. Pego num\u00a0<a href=\"http:\/\/en.wikipedia.org\/wiki\/Web_Services_Description_Language\" target=\"_blank\" rel=\"noopener\">WSDL<\/a>\u00a0(que \u00e9 a defini\u00e7\u00e3o do webservice em XML) e gero uma molhada de c\u00f3digo que sabe tratar aquilo. Desde que n\u00e3o se tenha que olhar para o c\u00f3digo gerado, est\u00e1 tudo bem. Mas a\u00a0<a href=\"https:\/\/web.archive.org\/web\/20120327223626\/http:\/\/www.joelonsoftware.com\/articles\/LeakyAbstractions.html\" target=\"_blank\" rel=\"noopener\">law of leaky abstractions<\/a>\u00a0diz-nos que mais cedo ou mais tarde vamos ter que olhar para o c\u00f3digo. E nessa altura, vamos chamar bastantes nomes ao SOAP e aos seus geradores de c\u00f3digo.<\/li>\n<li>Um padr\u00e3o recorrente em aplica\u00e7\u00f5es Web \u00e9 a disponibiliza\u00e7\u00e3o da mesma funcionalidade via HTML e via Webservice. Se o WebService f\u00f4r REST podemos reutilizar tudo menos a apresenta\u00e7\u00e3o, que no primeiro caso \u00e9 em HTML e no segundo em XML. Isto porque o request HTTP \u00e9 exactamente igual. Se f\u00f4r em SOAP, practicamente temos que refazer\/duplicar a componente servidor.<\/li>\n<li>Se pensarmos em aplica\u00e7\u00f5es Web de grande escala, o SOAP \u00e9 a morte do artista. Primeiro porque as ferramentas insistem que se carregue sempre toda a mensagem para mem\u00f3ria num DOM de objectos. N\u00e3o podemos ir processando incrementalmente (<em>streaming<\/em>), tem que ir tudo para mem\u00f3ria. Em REST, fazer streaming \u00e9 limpinho: \u00e9 s\u00f3 obter um InputStream para a HttpConnection (em Java, noutras linguagens h\u00e1-de ser semelhante) e ir consumindo ao ritmo que entendermos. Por outro lado, juntando o peso de envelopar\/desenvelopar as mensagens SOAP ao facto de os mecanismos de caching na Web n\u00e3o se aplicarem, temos um caso bicudo se planearmos receber mais do algumas dezenas de pedidos Webservice por minuto.<\/li>\n<li>Dito isto, por vezes temos necessidade de implementar webservices em SOAP, seja por que o cliente comprou a ferramenta X, ou porque as aplica\u00e7\u00f5es clientes querem usar SOAP, etc. Nesse caso, sugiro uma ferramenta do tipo do\u00a0enunciate\u00a0que, pelo menos, garante que sem esfor\u00e7o adicional temos webservices para todos os gostos (UPDATE 2018: o enunciate j\u00e1 n\u00e3o existe e tanto quanto sei n\u00e3o h\u00e1 ferramentas que providenciem com pouco esfor\u00e7o as duas op\u00e7\u00f5es).<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>Quem tenha lidado com\u00a0webservices\u00a0nos \u00faltimos tempos, ou se deparou com o\u00a0debate SOAP vs REST, ou andou com a cabe\u00e7a enfiada na areia. Para quem andou com a cabe\u00e7a enfiada na areia, aqui vai um resumo pragm\u00e1tico: Um webservice \u00e9 uma maneira de uma\u00a0aplica\u00e7\u00e3o\u00a0comunicar com um servidor Web. Tradicionalmente, quem interage com um servidor web \u00e9 [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_mi_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_newsletter_tier_id":0,"footnotes":"","jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false}}},"categories":[5],"tags":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p7ZDEQ-C","_links":{"self":[{"href":"http:\/\/www.inospito.net\/wp-json\/wp\/v2\/posts\/38"}],"collection":[{"href":"http:\/\/www.inospito.net\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.inospito.net\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.inospito.net\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.inospito.net\/wp-json\/wp\/v2\/comments?post=38"}],"version-history":[{"count":1,"href":"http:\/\/www.inospito.net\/wp-json\/wp\/v2\/posts\/38\/revisions"}],"predecessor-version":[{"id":39,"href":"http:\/\/www.inospito.net\/wp-json\/wp\/v2\/posts\/38\/revisions\/39"}],"wp:attachment":[{"href":"http:\/\/www.inospito.net\/wp-json\/wp\/v2\/media?parent=38"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.inospito.net\/wp-json\/wp\/v2\/categories?post=38"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.inospito.net\/wp-json\/wp\/v2\/tags?post=38"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}