 |
Search |
 |
|
|
SOAP and REST - both equally important to SunPosted by arungupta on October 17, 2008 at 3:33 PM PDT
"Sun moving away from SOAP to embrace REST" is the misleading title of an article recently published in SD Times. The article provides a good introduction to JAX-RS and Jersey. But I really wonder what motivated the author of this article to use this title. This blog, hopefully, provides a better context. Jersey is the Reference Implementation of Java API for RESTful Web Services (JAX-RS, JSR 311) and was released earlier this week. The headline indicates that Sun is leaving SOAP and will support REST. The debate between REST and SOAP is not new and there are religious camps on both sides (even within Sun). And that's completely understandable because each technology has its own merits and demerits. But just because a new JSR aimed to make RESTful Web services easy in the Java platform is released, it does not mean Sun Microsystems is leaving existing technology in trenches. The addition of Jersey to Sun's software portfolio makes the Web services stack from GlassFish community a more compelling and comprehensive offering. This is in contrast to "moving away" from SOAP as indicated by the title. As a matter of fact, Jersey will be included as part of Metro soon, the Web Services stack of GlassFish. And then you can use JAX-WS (or Metro) if you like to use SOAP or JAX-RS (or Jersey) if you prefer RESTful Web services. It's all about a offering choice to the community instead of showing a direction. Here are some data points for JAX-WS:
You still think Sun is moving away from SOAP ? It seems a personal preference is interpreted as Sun's disinvestment in SOAP. It's good to have increased readership but not at the cost of misleading headlines :) Technorati: jax-ws rest webservices metro sdtimes glassfish »
Related Topics >>
Web Services and XML Comments
Comments are listed in date ascending order (oldest first)
Submitted by jwenting on Mon, 2008-10-20 22:53.
REST is to SOAP what cooking stone soup is to gourmet dining.
Submitted by marvi on Tue, 2008-10-21 04:52.
Or
REST is to SOAP what running on a beach is to running in quicksand.
I like how the number of jar file dependencies in an application grows 4x when you add SOAP support to it.
Submitted by coding on Mon, 2008-10-20 09:59.
This entire debate is pointless, they are not even competing technologies. I think the reason why people think they are competing is because too many people thought SOAP was the way to go back before the REST concept was huge. One major reason SOAP will never go away is standards based - contract specified - services. Those services that can't be implemented a billion different ways. As I understand it, REST isn't a contract first design, which means you can't build standard interfaces on it that multiple competitors implement.
Submitted by jwenting on Mon, 2008-10-20 00:46.
why wonder? The title is hype. Hype sells. Would you have started reading the thing if it'd had a title like "Sun getting interested in REST"?
Submitted by jhannes on Fri, 2008-10-31 12:40.
"As I understand it, REST isn't a contract first design"
REST doesn't enforce a contract first design, but most sane RESTafarians will define their XSD. On the other hand, SOAP doesn't *enforce* contract first, either. Most toolkits seem to encourage generating the WSDL from code.
I think you're about as likely to see a contract-first approach in either case.
Meanwhile, the semantics of SOAP services are less likely to be standardized. Nothing tells the stack that getCustomer and findOrder both are reading operations. On the other hand GET /order/xxxx and GET /customer/xxx is the same sort of thing, and can potentially be treated as the same by the stack.
|
|
|
||
|
