[PJUG Javamail] SOAP or REST?

[Kent Spaulding]

I wish I could remember the source, but it's lore that WS*, including  
WSDL, has been designed to *require* tools - boosting software revenue.

Cynical, I know.

Given a choice (i.e. you control the client and server), use a RESTful  
architecture.  That may or may not use SOAP; however, it's important  
to recall that http is an application layer protocol, despite the fact  
that, given firewalls and proxies, it's commonly used as a transport  
protocol.  SOAP treats http as a transport protocol, but it seems to  
best to use http as intended - so RESTful, without SOAP.

--Kent

On Mar 19, 2009, at 8:10 AM, Brian Mason wrote:

> I have been out of the web service market for about 3 years, but if I
> remember right, WSDL was a pretty BAD interface definition format.
> There were 4 different variations on calling convention and parameter
> packaging and you had to get the right combination to support the
> expensive tools.  I think there was one combination that would work
> for .net and the WSDL compiler from JEE.
> Is this still the case?
>
> Brian.
>
> On Wed, Mar 18, 2009 at 10:07 PM, Howard Abrams <howard.abrams at gmail.com 
> > wrote:
>> Let me add my 3 cents.
>>
>> Web services is all about loosely coupling services/components, and
>> the *interface* really depends on your customer's demands.
>>
>> I've found that the biggest advantage of SOAP is the tool automation
>> and the maturity in that arena. Once you have built your WSDL (the
>> equivalent REST version isn't done yet), other tools can look at it
>> and easily connect to it. However, as has been already mentioned,
>> these tools are typically in the "Enterprise" space, and come with
>> "Enterprise" price tags. If you have Enterprise clients as your
>> customer, you may want to choose SOAP.
>>
>> Since RESTful interfaces are easier to *program* against, most
>> programmers will prefer REST over SOAP. REST generally makes the most
>> sense when you can control both the client and the server.
>>
>>
>> On Mar 18, 2009, at 7:17 PM, Nimret Sandhu wrote:
>>
>>> On Wednesday 18 March 2009 04:31:53 pm Bill Jackson wrote:
>>>> Yes, absolutely.  (I have never used these words before, but please
>>>> remember this is my opinion and not necessarily my employer's.)
>>>> REST is
>>>> self-contained, dead simple to use, and its descriptive URLs are a
>>>> thing of
>>>> beauty; IMHO, it is a no-brainer in cases where the complexity and
>>>> overhead
>>>> of SOAP make no sense.
>>>
>>> to elaborate on the 'descriptive URLs' observation here, REST
>>> provides a more
>>> OO style RPC api while SOAP is more of a flat procedural style RPC
>>> interface.
>>> Eg: http://www.xfront.com/REST-Web-Services.html
>>>
>>> REST uses HTTP specifically while SOAP is supposed to be protocol
>>> agnostic (
>>> eg SOAP over SMTP).
>>>
>>> SOAP is also more of an enterprise industry 'standard' so you may
>>> find more
>>> support for it in enterprise products which you might want to be
>>> interoperable with or provide interoperability for. REST appears to
>>> be more
>>> prevalent in the world wild web ( pun intended :) and not so much
>>> within
>>> products per se.
>>>
>>> SOAP is built on top of XML ( request + response) while REST
>>> responses can be
>>> XML, JSON, binary data, whatever. Yeah, SOAP can also return those
>>> data types
>>> but you have the additional overhead of binding those to XML (
>>> de+serialization).
>>>
>>> As someone already recommended, I used ApacheCXF at my last job to
>>> implement
>>> both a SOAP and a REST interface. I used the JAX-WS spec to create  
>>> the
>>> services which should allow switchable implementations with  
>>> deployment
>>> changes only ( theoretically :)
>>>
>>> Note that a browser fetching resources from the World Wild Web is an
>>> example
>>> of RESTful architecture.
>>>
>>> regards -
>>> --
>>> Nimret Sandhu
>>> http://www.nimret.com
>>> http://www.nimsoft.biz
>>> _______________________________________________
>>> Web Site - http://www.pjug.org/
>>> Javamail mailing list
>>> Javamail at pjug.org
>>> http://www.pjug.org/mailman/listinfo/javamail
>>
>> _______________________________________________
>> Web Site - http://www.pjug.org/
>> Javamail mailing list
>> Javamail at pjug.org
>> http://www.pjug.org/mailman/listinfo/javamail
>>
> _______________________________________________
> Web Site - http://www.pjug.org/
> Javamail mailing list
> Javamail at pjug.org
> http://www.pjug.org/mailman/listinfo/javamail