REST and SOAP Guidelines

Nov 19, 2008 at 8:00 PM

pg. 172 - REST can be implemented over other protocols, such as JSON and custom Plain Old XML
(POX) formats.


    It seems like this statement is mixing two different concepts, resource representations (data formats) and application protocols. JSON is not a protocol, it's a data format which can be used for a resource representation. POX is also not a protocol. It's typically used to describe services that are somewhere in between WS-* and RESTful. Other protocol examples could be AtomPub or WebDav.

In general I don't really understand what these guidelines are trying to present. For example we have this statement:

SOAP handles issues such as security and addressing through its internal protocol implementation, but requires a SOAP stack to be available.

    Yet there is no mention of how security and addressing are incorporated using a RESTful service design. I understand security is orthogonal to REST, but some people might be misled into thinking REST has no security options, if only SOAP security is mentioned. It seems like the guidelines need more balance and detail to really assist in choosing one style or the other.
Nov 20, 2008 at 1:06 AM
Good points.  This is one of the sections that we are doing more research on to get it right. We agree they need more balance and precision.

We don't want to start a debate on  REST vs SOAP, but we would like to present the options. Do you use REST based systems a lot in your programming?  If so,
1) Which scenarios would you use REST in vs SOAP?
2) How do you implement security in REST?  https or do you have another way?
3) What are the benefits you've seen for using REST over SOAP.  Feel free to be specific to how it's helped you in your project.

Here are some notes I've been gathering from various sources. Don't take these as truth, but rather talking points to bounce and opinion off of.  

SOAP

    SOAP is really WSDL, even though two specs are different.

    WSDL is really cobra with angle brackets < > . cobra is about distributed objects.  Marshalling.

    WS-addressing was actually separate from SOAP spec. If look at SOAP + WS addressing looks very RESTful.

 

    Not necessarily http based

    transport agnostic.

    Intranet scenarios.

 

    If look at SOAP + WS addressing looks very RESTful.

   

Benefits

    Great in integrating differing legacy backend systems

       Ex. front end ASP.NET,  backend JBD

     Transactions (WS - AT supoprt in SOAP)

     Reliability (WS- RM support in SOAP)

     Security a lot of options

     Message based security

     partial encryption

 

Issues

     High barrier to entry.  Need a lot of plumbing to set up SOAP.

     WCF and other methods don’t take away this plumbing yet.

REST

 

Benefits

 

   REST advantages  - extranet. When everything is http based

   Extranet scenario.  Because everyone based on http and port 80

   Low barrier to entry.

   Simplicity  (perceived?)    

Issues

   Client needs to have prior knowledge to know what's there

   What is returned? employee ID?

   http based only

   security is just https.  

   not really hypertext  - usually JSON, XML. What makes it different from "Fielding" REST

   URLs have structure.  Need to know something about the URL?   

   PERCEIVED simplicity.  Not as flexible in the long term. 
 

   REST Does NOT work with

     Transactions (WS - AT support in SOAP)

     Reliability (WS- RM support in SOAP)

   Partial Encryption (WS-SEC*)

   Message based security

 
Jan 9, 2009 at 1:32 AM
We greatly changed the REST vs SOAP section in the final Guide published on 12/15/2008.  If you are running across this comment, know that it was updated.
Jan 12, 2013 at 4:48 AM

On sale barbour jacket with surprising discount are waiting for you in barbour sale online. For  cold winter days, we have prepared you with warm quilted barbour jacket , classic barbour international , quality barbour wax and other barbour coat in online barbour store . Be quick to take those cheap barbour jackets home!

http://www.barbourbymall2013.com/