Comments on: SOAP vs. REST http://spf13.com/post/soap-vs-rest Wed, 16 May 2012 09:39:00 +0000 hourly 1 http://wordpress.org/?v=3.3 By: Anonymous http://spf13.com/post/soap-vs-rest#comment-461 Anonymous Wed, 02 May 2012 16:13:00 +0000 http://localhost/~sfrancia/wordpress/?p=121#comment-461 This post has delivered a consistently steady trickle of links to my blog ("Why SOAP sucks") over the past two years. I assume people search Google for "SOAP vs REST", get sent here, then read far enough to click the links. I'm a little surprised this topic is so popular. My own opinion is SOAP has no purpose in the world now except as a legacy technology. XML is wrong; use JSON. And the SOAP efforts at packaging communications are a failure. You're quite polite in highlighting the advanced WS-* features as being useful for solving problems. I think they are good attempts, but I wouldn't trust either the design or implementation of any of them for anything important. This post has delivered a consistently steady trickle of links to my blog (“Why SOAP sucks”) over the past two years. I assume people search Google for “SOAP vs REST”, get sent here, then read far enough to click the links. I’m a little surprised this topic is so popular.

My own opinion is SOAP has no purpose in the world now except as a legacy technology. XML is wrong; use JSON. And the SOAP efforts at packaging communications are a failure. You’re quite polite in highlighting the advanced WS-* features as being useful for solving problems. I think they are good attempts, but I wouldn’t trust either the design or implementation of any of them for anything important.

]]> By: SOAP vs REST | DLS Software Studios http://spf13.com/post/soap-vs-rest#comment-450 SOAP vs REST | DLS Software Studios Mon, 09 Apr 2012 12:39:25 +0000 http://localhost/~sfrancia/wordpress/?p=121#comment-450 [...] Interested in reading more? Check out his article at SFP13.com. [...] [...] Interested in reading more? Check out his article at SFP13.com. [...]

]]> By: adel kraiem http://spf13.com/post/soap-vs-rest#comment-426 adel kraiem Tue, 28 Feb 2012 10:09:00 +0000 http://localhost/~sfrancia/wordpress/?p=121#comment-426 Great Blog. Thx Great Blog. Thx

]]> By: adel kraiem http://spf13.com/post/soap-vs-rest#comment-427 adel kraiem Tue, 28 Feb 2012 10:09:00 +0000 http://localhost/~sfrancia/wordpress/?p=121#comment-427 Great Blog.; Thx  Great Blog.; Thx 

]]> By: SOAP Webservices mit iOS | codecentric Blog http://spf13.com/post/soap-vs-rest#comment-390 SOAP Webservices mit iOS | codecentric Blog Mon, 02 Jan 2012 08:20:40 +0000 http://localhost/~sfrancia/wordpress/?p=121#comment-390 [...] Techniken grundsätzlich überhaupt verglichen werden sollten – damit haben sich andere bereits ausreichend [...] [...] Techniken grundsätzlich überhaupt verglichen werden sollten – damit haben sich andere bereits ausreichend [...]

]]> By: SOAP web services with iOS | codecentric Blog http://spf13.com/post/soap-vs-rest#comment-389 SOAP web services with iOS | codecentric Blog Mon, 02 Jan 2012 05:03:35 +0000 http://localhost/~sfrancia/wordpress/?p=121#comment-389 [...] of REST and SOAP or a discussion of whether they should be compared at all – others have done that at great depth [...] [...] of REST and SOAP or a discussion of whether they should be compared at all – others have done that at great depth [...]

]]> By: Tasman Hayes http://spf13.com/post/soap-vs-rest#comment-376 Tasman Hayes Wed, 30 Nov 2011 07:25:00 +0000 http://localhost/~sfrancia/wordpress/?p=121#comment-376 I've used SOAP from a website to a web coupon published to pull coupons. It worked great. I've also used SOAP between a web app (PHP) and billing app (MS Basic) to push orders and pull back billing amounts. It works well for this app too. SOAP can work really well. I've had no issues with it. Reading your article and "Why Soap Sucks?" as well certainly gave me pause.  :-) SOAP hint: Cache the service definition (WSDL) for performance if you're doing a high volume of calls. This is configurable in PHP's SOAP implementation. I’ve used SOAP from a website to a web coupon published to pull coupons. It worked great.

I’ve also used SOAP between a web app (PHP) and billing app (MS Basic) to push orders and pull back billing amounts. It works well for this app too.

SOAP can work really well. I’ve had no issues with it.

Reading your article and “Why Soap Sucks?” as well certainly gave me pause.  :-)

SOAP hint: Cache the service definition (WSDL) for performance if you’re doing a high volume of calls. This is configurable in PHP’s SOAP implementation.

]]> By: When to use SOAP over REST | www.dotnetz.net http://spf13.com/post/soap-vs-rest#comment-370 When to use SOAP over REST | www.dotnetz.net Tue, 22 Nov 2011 03:32:24 +0000 http://localhost/~sfrancia/wordpress/?p=121#comment-370 [...] Francia, S. (2010). SOAP vs. REST. Retrieved 11 20, 2011, from spf13: http://spf13.com/post/soap-vs-rest [...] [...] Francia, S. (2010). SOAP vs. REST. Retrieved 11 20, 2011, from spf13: http://spf13.com/post/soap-vs-rest [...]

]]> By: E S http://spf13.com/post/soap-vs-rest#comment-345 E S Fri, 14 Oct 2011 22:29:00 +0000 http://localhost/~sfrancia/wordpress/?p=121#comment-345 A good summary of some important points, but I don't know that I really agree that the web doesn't care much about ACID transactions. Many applications do things that require ACID transactions such as updating multiple items at once, moving items from one group to another, or cascading deletes. And web applications are just applications like any other so why should that factor in? Maybe you can explain further regarding what parts of ACID don't apply to the web? A good summary of some important points, but I don’t know that I really agree that the web doesn’t care much about ACID transactions. Many applications do things that require ACID transactions such as updating multiple items at once, moving items from one group to another, or cascading deletes. And web applications are just applications like any other so why should that factor in? Maybe you can explain further regarding what parts of ACID don’t apply to the web?

]]> By: SOAP vs REST » Tech Blog http://spf13.com/post/soap-vs-rest#comment-332 SOAP vs REST » Tech Blog Fri, 30 Sep 2011 12:41:12 +0000 http://localhost/~sfrancia/wordpress/?p=121#comment-332 [...] http://spf13.com/post/soap-vs-rest Posted by shahprashant at 4:41 am [...] [...] http://spf13.com/post/soap-vs-rest Posted by shahprashant at 4:41 am [...]

]]> By: Igory Lr http://spf13.com/post/soap-vs-rest#comment-313 Igory Lr Wed, 27 Jul 2011 19:51:00 +0000 http://localhost/~sfrancia/wordpress/?p=121#comment-313 I case of "methods vs. resources" REST also wins. Just encode method calls to URIs. You have the benefit of not being tied to XML. Sure you can transfer anything in XML too but you need to encode/decode it to/from base64. I case of “methods vs. resources” REST also wins. Just encode method calls to URIs. You have the benefit of not being tied to XML. Sure you can transfer anything in XML too but you need to encode/decode it to/from base64.

]]> By: Bryan Taylor http://spf13.com/post/soap-vs-rest#comment-217 Bryan Taylor Sat, 02 Apr 2011 07:26:00 +0000 http://localhost/~sfrancia/wordpress/?p=121#comment-217 WS-ReliableMessaging guarantees only reliable transport, not reliable application processing and thus is unsuitable for reliable messaging. To see why WS-RM simply fails to achieve reliable messaging, see http://www.infoq.com/articles/no-reliable-messaging. The RESTful way to do reliable messaging is to use idempotency. Either use GET until the subsequent processing succeeds as defined by the client, or use PUT followed by a verification GET until both work. Generally, the first solution is much better, because recievers are much better positioned to be responsible for reliable delivery. Atom with archiving demonstrates good reliable delivery. WS-AtomicTransactions. Distributed transactions are an antipattern. Ban them. If eBay can make payments between accounts at their auction site and paypal without them, so can you. Distributed transactions destroy your scalability, and they force you to give up either availability or network fault tolerance (CAP theorem). Use compensating transactions instead. If you need consistency, define a single source of truth and do ACID transactions within it. WS-Security. This protocol is about achieving end-to-end security by using encryption and cryptographic signing to assure that messages may pass through intermediaries of lower trust without fear of tampering or disclosure. A better way to do this is to create an encrypted transport channel all the way from one endpoint to the other. This is called SSL. If you had to, you could make your representations contain encrypted and/or signed content using your favorite technologies for this. Only a middleware vendor would see any value in coupling this to your transport mechanism, though. WS-ReliableMessaging guarantees only reliable transport, not reliable application processing and thus is unsuitable for reliable messaging. To see why WS-RM simply fails to achieve reliable messaging, see http://www.infoq.com/articles/no-reliable-messaging. The RESTful way to do reliable messaging is to use idempotency. Either use GET until the subsequent processing succeeds as defined by the client, or use PUT followed by a verification GET until both work. Generally, the first solution is much better, because recievers are much better positioned to be responsible for reliable delivery. Atom with archiving demonstrates good reliable delivery.

WS-AtomicTransactions. Distributed transactions are an antipattern. Ban them. If eBay can make payments between accounts at their auction site and paypal without them, so can you. Distributed transactions destroy your scalability, and they force you to give up either availability or network fault tolerance (CAP theorem). Use compensating transactions instead. If you need consistency, define a single source of truth and do ACID transactions within it.

WS-Security. This protocol is about achieving end-to-end security by using encryption and cryptographic signing to assure that messages may pass through intermediaries of lower trust without fear of tampering or disclosure. A better way to do this is to create an encrypted transport channel all the way from one endpoint to the other. This is called SSL. If you had to, you could make your representations contain encrypted and/or signed content using your favorite technologies for this. Only a middleware vendor would see any value in coupling this to your transport mechanism, though.

]]> By: Anonymous http://spf13.com/post/soap-vs-rest#comment-216 Anonymous Fri, 01 Apr 2011 16:29:00 +0000 http://localhost/~sfrancia/wordpress/?p=121#comment-216 I'm not convinced by your "financial transactions require SOAP" argument. Here is my counter argument: how is it that I do financial transactions (as millions of other people do) using my bank website from my web browser, without the help from SOAP and all the WS technologies you mention? I’m not convinced by your “financial transactions require SOAP” argument. Here is my counter argument: how is it that I do financial transactions (as millions of other people do) using my bank website from my web browser, without the help from SOAP and all the WS technologies you mention?

]]> By: Anonymous http://spf13.com/post/soap-vs-rest#comment-215 Anonymous Fri, 01 Apr 2011 16:20:00 +0000 http://localhost/~sfrancia/wordpress/?p=121#comment-215 REST/HTTP has a defined interface: it is the HTTP spec. You'll find the definitions of methods, status code and so on. Conent exchanged over HTTP requests/responses isusualy either specified in additional standard ocuments (i.e., XHTML, ATOM, etc.) or in your own doc (e.g., XML schema, etc.) REST/HTTP has a defined interface: it is the HTTP spec. You’ll find the definitions of methods, status code and so on. Conent exchanged over HTTP requests/responses isusualy either specified in additional standard ocuments (i.e., XHTML, ATOM, etc.) or in your own doc (e.g., XML schema, etc.)

]]> By: Anonymous http://spf13.com/post/soap-vs-rest#comment-214 Anonymous Fri, 01 Apr 2011 08:16:00 +0000 http://localhost/~sfrancia/wordpress/?p=121#comment-214 Point for SOAP: There is a defined interface included (as WSDL) and any client can use it without problems while updating the service. The usage of a REST interface is described mostly on a wiki page. Point for REST: No problems with incompatibility with different SOAP-client/server. But you got the other point: SOAP address methods, REST address resources. Point for SOAP: There is a defined interface included (as WSDL) and any client can use it without problems while updating the service. The usage of a REST interface is described mostly on a wiki page.

Point for REST: No problems with incompatibility with different SOAP-client/server.

But you got the other point: SOAP address methods, REST address resources.

]]>