Thread: Soap vs rest

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.

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?

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.

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 Bugbyte

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.

Originally Posted by Bugbyte

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.

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.

Originally Posted by justchat_1

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.

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>