We have been using SOAP based web services in our J2EE application. Now there is a requirement of having client for RESTful web services. If we are going to have client for RESTful, is there any problem? Does it mean that not consistent Architecture?
+1
A:
SOAP is a message protocol, REST is a design/architectural philosophy. In what means are you trying to compare and contrast them? Web Services that communicate via SOAP can be RESTful, or not, depending on the design.
If by RESTful you mean "Management wants the URLs to look like http://example.com/shoppingcart/123/addItem/456 " then it really shouldn't be a big deal with any half decent framework to have both types of requests end up at the same service method with minimal work to route them. Having the magic "RESTy looking URLs" doesn't make your service inherently any more or less RESTful. Lots of services with the "REST look" are highly coupled to a stateful server side.
Affe
2010-07-29 05:31:46
My Question was Big Web Services and RESTful Web Services. As per my knowledge Big Web Services use SOAP, XML, WSDL etc , where as RESTful web Services use HTTP. So can we have both Big Web Services and RESTful wb services in our application?
2010-07-29 05:49:14
Is it technologically possible? Sure, of course. You could expose the subset of your operations that are REST-compliant via a different transport/interface. Personally, I would go back and grill the person who writes/gathers my requirements and find out if they really mean/want a REST-compliant web service, or if they just mean they want people to be able to use the existing service through an httpclient library without a SOAP stack and WSDL. I would wager brews it's the later. :)
Affe
2010-07-29 06:17:27