Which web service messaging approach do you prefer? | Java.net

My pages	Projects	Communities	java.net

Get Involved About java.net Request a Project Publicize your Project Submit Content java-net Project Java.net Enhancements Site Help Report Inappropriate Content Get Informed Articles Blogs Events java.net Online Books java.net Archives Get Connected java.net Forums Wiki Javapedia People Partners Jobs RSS Feeds Java User Groups Search Web and Projects: Online Books: java.net on MarkMail: Advanced Search
		Which web service messaging approach do you prefer? SOAP 24% (115 votes) REST 30% (145 votes) I like both 15% (71 votes) I don't like either 10% (47 votes) I like something else (please comment) 4% (19 votes) I don't work with web services 17% (83 votes) Total votes: 480 » Login or register to post comments 288 visits Printer-friendly version Transport vs. Message Submitted by trinition on Tue, 2008-10-21 06:52. One good contract I heard is that with REST, you rely on the transport for much (encryption via HTTPS, meta data in HTTP headers, etc.), whereas in SOAP, the message does (e.g. encrypted payloads in SOAP message, SOAP headers, etc.). The difference becomes important because a SOAP message can be delivered by any transport (e.g. queue, asynchronous FTP, store-and-forward SMTP). Is a REST message stuck in HTTP? What's more, encryption/decryption costs are paid at each HTTP endpoint whereas a SOAP payload would only need be decrypted at its destination (not to mention your data isn't exposed along the way). I personally don't yet have a preference, but I'm eager to see how those who do respond to this contrast. Login or register to post comments Transport vs. Message Submitted by prime21 on Tue, 2008-10-21 20:17. One of the many benefits of REST is that you can (and typically do) leverage the HTTP transport. In the common case where you need encryption, you would typically relying on HTTPS between two end-points. However, if you need to encrypt your payload (because it will be transmitted through multiple insecure end-points, or whatever), then you're free to do that. REST doesn't prevent this in any way. REST merely asks that you adjust the MIME type to match the format of whatever you're transmitting. So an SMTP message, or an HTTP response, or any number of transports could be used to transmit an encrypted RESTful resource. I don't have a problem with SOAP. But I doubt, I'll ever write a SOAP based web service again. The complexity is high and the scalability is low when compared to REST. -Bryan Login or register to post comments Transport vs. Message Submitted by hrastnik on Wed, 2008-10-22 01:02. A constitutive building block of REST is to employ the semantics of HTTP methods (POST, GET, PUT, etc.). Therefore, there is difference between, for example, a POST and a PUT request having the same payload. So how do you integrate the method semantics when using SMTP? Is there a standardized way to do so? Are there standardized ways for other protocols as well? Login or register to post comments XML-RPC Submitted by skipper13 on Tue, 2008-10-21 02:30. It's simpier than SOAP Login or register to post comments XML-RPC Submitted by uhilger on Thu, 2008-10-23 07:38. I also prefer XML-RPC for its simplicity over SOAP. Login or register to post comments