Announcement

Collapse
No announcement yet.

Soap vs rest

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Soap vs rest

    Matt did something similar, but I just wanted to post a pros/cons list of my own and finalize the debate over the protocol/data transfer mechanism:

    SOAP

    Pros:
    - Supports Complex arguments and return types
    - Can generate code from WSDL (no parsing on client)
    - Supports Security and Encryption.

    Cons:
    - Heavier protocol when compared to REST

    REST

    Pros:
    - Lightweight for simple calls
    - Supports return results in XML

    Cons:
    - Client still has to do parsing (this will likely be abstracted via the OSDash Client library/assembly).

    I'm sure there are more pros/cons to each. Personally, I think the code generation and automatic parsing is the killer feature of SOAP. I'd like to hear what other people think on the debate. I'll keep this OP updated with additional pro's con's as comments appear...
    Former author of LinuxICE, nghost, nobdy.
    Current author of Automotive Message Broker (AMB).
    Works on Tizen IVI. Does not represent anyone or anything but himself.

  • #2
    If you can stick with simple data types, using a RESTful approach is the easiest. Although simple data types may not be possible for all all web calls.

    However, we may not need to decide. If using the C# (.NET) programming language, it automatically provides support for both. Look at my example below.

    Webservice Call
    Code:
    [WebMethod(Description = "Returns search results for custom searches")]
            public SearchLocations[] Search(double longitude, double latitude, string searchtext)
            {
                GoogleConnector myConnect = new GoogleConnector();
                GPSLocation myGPS = new GPSLocation(longitude, latitude);
                return myConnect.Search(searchtext, myGPS);
            }

    Soap Call

    Code:
    POST /DrivnOnline.asmx HTTP/1.1
    Host: localhost
    Content-Type: text/xml; charset=utf-8
    Content-Length: length
    SOAPAction: "http://nextabyte.com/webservices/Search"
    
    <?xml version="1.0" encoding="utf-8"?>
    <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
      <soap:Body>
        <Search xmlns="http://nextabyte.com/webservices">
          <longitude>double</longitude>
          <latitude>double</latitude>
          <searchtext>string</searchtext>
        </Search>
      </soap:Body>
    </soap:Envelope>
    RESTful Call
    Code:
    POST /DrivnOnline.asmx/Search HTTP/1.1
    Host: localhost
    Content-Type: application/x-www-form-urlencoded
    Content-Length: length
    
    www.somewebsite.com/servicename/Search?longitude=string&latitude=string&searchtext=string

    While RESTful is the easiest to do for simple functions with basic datatypes.... NOT ALL FUNCTIONS will allow for simple datatypes. For client-webservice calls, I think the best way to go is full SOAP compatibility. While harder to use, it offers so much more functionality.

    However, for web front-ends, RESTful is a must as using SOAP is much more complex using PHP and HTML. For calls made by web calls, REST should be used if possible.

    Comment


    • #3
      You should add proprietary verse open to the pro/con list

      I would definitely put my vote in for REST for the simplicity, lack of bloat and backwards compatibility. I would also be curious for an example of a properly designed web service that needed anything more then simple datatypes?
      openMobile - An open source C# Front End (why choose openMobile?)
      - Always Recruiting Developers -
      Like what you see? Donations are always welcome

      Comment


      • #4
        Not sure if you mean SOAP or REST as being proprietary. But neither one is proprietary. SOAP least of all. The advantage of SOAP is that is has full, well defined, and supported standards in the WS-* stack. REST is just an architectural concept that is based on using HTTP and XML, both open standards.

        Using REST (HTTP/XML) ensures all sorts of technologies and devices can integrate with the services, as long as the client can do XML and HTTP. The full SOAP stack is not always supported everywhere. Also, SOAP tends to be far more verbose than simple XML serialization. Something to keep in mind since a lot of people may be using pay-as-you-go or limited mobile data plans.

        Also, you can absolutely use complex data types in REST. In fact (for either SOAP or REST), I would highly recommend using request/response objects to enclose the parameters to your service calls rather than passing a large list of parameters. This makes updating and versioning the services easier.

        So you could have a C# class for location such as:

        Code:
            [DataContract(
                Name="location",
                Namespace="http://osdash/models/2009/12")]
            public class Location
            {
                [DataMember(Name = "latitude")]
                public double Latitude { get; set; }
        
                [DataMember(Name = "longitude")]
                public double Longitude { get; set; }
            }
        An instance will serialize as such:

        Code:
        <location xmlns="http://osdash/models/2009/12">
           <latitude>0</latitude>
           <longitude>0</longitude>
        </location>
        For generating proxies, you could publish schemas to your objects. Most languages have tools to serialize from objects to XML and vice-versa.

        For versioning, let's say you publish a Location service with an update call that takes the Location object above. For some reason you later decide the Location object should also have speed and heading values. You don't need to change your service interface or code, just the Location definition. You could then make the new values optional so legacy clients can still use your service without causing breaking changes.
        EWF, HORM, MinLogon on XP.

        Zotac ION Atom N330, 2GB low-profile RAM, M3-ATX
        Win Embedded Std 2011 RC
        OCZ Vertex Turbo 30GB SSD
        Lilliput 629 Transflective, WRX Screen Mount
        BlueSoleil BT, i-Blue GM-2 GPS, DirectedHD Radio, Andrea Mic
        VoomPC 2

        Comment


        • #5
          When you say "complex data types" what do you mean, something like an array or maybe a streaming audio file or...?

          Is it possible for the standard to support both RESTful AND SOAP? Although it does seem that mainly REST is sufficient for now, who knows what future services may need? Is there a clever way to specify the type in a header or with a software swith or the like? That might allow for future service types to be added while keeping legacy support...
          Originally posted by ghettocruzer
          I was gung ho on building a PC [until] just recently. However, between my new phone having internet and GPS and all...and this kit...Im starting to have trouble justfiying it haha.
          Want to:
          -Find out about the new iBug iPad install?
          -Find out about carPC's in just 5 minutes? View the Car PC 101 video

          Comment


          • #6
            Originally posted by Bugbyte View Post
            When you say "complex data types" what do you mean, something like an array or maybe a streaming audio file or...?
            Simple Data Types
            • integer
            • string
            • boolean

            Complex Data Types
            • Objects
            • Arrays
            • Structs

            Streaming audio is somewhat out of the scope at the moment. I dont think anyone here has the knowledge of setting up their own format/protocol. We would need to use 3rd party tools to accomplish this.

            Comment


            • #7
              Originally posted by Bugbyte View Post
              Is it possible for the standard to support both RESTful AND SOAP? Although it does seem that mainly REST is sufficient for now, who knows what future services may need? Is there a clever way to specify the type in a header or with a software swith or the like? That might allow for future service types to be added while keeping legacy support...
              Look at my post above. I showed how the same function can accept both SOAP and RESTful function calls. Unless a complex datatype is requested in the function, a function can support both types.

              Comment


              • #8
                REST has full support for arrays and structs and theres never a case where a generic object should be used in a web service. Supporting both where possible is certainly a good idea (using the method above) but I think the preferred choice was REST, especially on low bandwidth mobile connections.
                openMobile - An open source C# Front End (why choose openMobile?)
                - Always Recruiting Developers -
                Like what you see? Donations are always welcome

                Comment


                • #9
                  Originally posted by justchat_1 View Post
                  REST has full support for arrays and structs and theres never a case where a generic object should be used in a web service. Supporting both where possible is certainly a good idea (using the method above) but I think the preferred choice was REST, especially on low bandwidth mobile connections.
                  Whats the call format for using a complex data type with REST? My C# example doesnt show a REST example whenever I compile with complex data types.

                  Comment


                  • #10
                    For WCF REST, using the Location object above all you do is define a service contract such as this:

                    Code:
                        [ServiceContract(Name="LocationService")]
                        public interface ILocationService
                        {
                            [OperationContract]
                            [WebGet(
                                BodyStyle=WebMessageBodyStyle.Bare,
                                RequestFormat = WebMessageFormat.Xml,
                                ResponseFormat = WebMessageFormat.Xml,
                                UriTemplate = "{user}")]
                            Location GetLocation(string user);
                         }
                    The HTTP traffic would like like this:

                    Code:
                    GET http://server/location/joe HTTP/1.1
                    Code:
                    HTTP/1.1 200 OK
                    Content-Length: 153
                    Content-Type: application/xml; charset=utf-8
                    
                    <location xmlns="urn:osdash/models/2009/12">
                    <latitude>0</latitude>
                    <longitude>0</longitude>
                    </location>
                    EWF, HORM, MinLogon on XP.

                    Zotac ION Atom N330, 2GB low-profile RAM, M3-ATX
                    Win Embedded Std 2011 RC
                    OCZ Vertex Turbo 30GB SSD
                    Lilliput 629 Transflective, WRX Screen Mount
                    BlueSoleil BT, i-Blue GM-2 GPS, DirectedHD Radio, Andrea Mic
                    VoomPC 2

                    Comment

                    Working...
                    X