REST vs SOAP Web Services
I
am seeing a lot of new web services are implemented using a REST style
architecture these days rather than a SOAP one. Lets step back a second and
explain what REST is.
What
is a REST Web Service
The
acronym REST stands for Representational State Transfer, this basically means
that each unique URL is a representation of some object. You can get the
contents of that object using an HTTP GET, to delete it, you then might use a
POST, PUT, or DELETE to modify the object (in practice most of the services use
a POST for this).
Who's
using REST?
All
of Yahoo's web services use REST, including Flickr, del.icio.us API uses it,
pubsub, bloglines, technorati, and both eBay, and Amazon have web services for
both REST and SOAP.
Who's
using SOAP?
Google
seams to be consistent in implementing their web services to use SOAP, with the
exception of Blogger, which uses XML-RPC. You will find SOAP web services in
lots of enterprise software as well.
REST
vs SOAP
As
you may have noticed the companies I mentioned that are using REST api's
haven't been around for very long, and their apis came out this year mostly. So
REST is definitely the trendy way to create a web service, if creating web
services could ever be trendy (lets face it you use soap to wash, and you rest
when your tired). The main advantages of REST web services are:
Lightweight
- not a lot of extra xml markup Human Readable Results Easy to build - no
toolkits required SOAP also has some advantages:
Easy
to consume - sometimes Rigid - type checking, adheres to a contract Development
tools For consuming web services, its sometimes a toss up between which is
easier. For instance Google's AdWords web service is really hard to consume (in
CF anyways), it uses SOAP headers, and a number of other things that make it
kind of difficult. On the converse, Amazon's REST web service can sometimes be
tricky to parse because it can be highly nested, and the result schema can vary
quite a bit based on what you search for.
Which ever architecture you choose
make sure its easy for developers to access it, and well documented.
|
218down voteaccepted |
REST is almost always going to be faster.
The main advantage of SOAP is that it provides a mechanism for services to
describe themselves to clients, and to advertise their existence.
REST is much more lightweight and can be
implemented using almost any tool, leading to lower bandwidth and shorter
learning curve. However, the clients have to know what to send and what to
expect.
In general, When you're publishing an API to
the outside world that is either complex or likely to change, SOAP will be
more useful. Other than that, REST is usually the better option.
|
|
up vote56down vote
|
REST vs SOAP Web Services
I am seeing a lot of new web services are
implemented using a REST style architecture these days rather than a SOAP
one. Lets step back a second and explain what REST is.
What is a REST Web Service
The acronym REST stands for Representational
State Transfer, this basically means that each unique URL is a representation
of some object. You can get the contents of that object using an HTTP GET, to
delete it, you then might use a POST, PUT, or DELETE to modify the object (in
practice most of the services use a POST for this).
Who's using REST?
All of Yahoo's web services use REST,
including Flickr, del.icio.us API uses it, pubsub, bloglines, technorati, and
both eBay, and Amazon have web services for both REST and SOAP.
Who's using SOAP?
Google seams to be consistent in
implementing their web services to use SOAP, with the exception of Blogger,
which uses XML-RPC. You will find SOAP web services in lots of enterprise
software as well.
REST vs SOAP
As you may have noticed the companies I
mentioned that are using REST api's haven't been around for very long, and
their apis came out this year mostly. So REST is definitely the trendy way to
create a web service, if creating web services could ever be trendy (lets
face it you use soap to wash, and you rest when your tired). The main
advantages of REST web services are:
Lightweight - not a lot of extra xml markup
Human Readable Results Easy to build - no toolkits required SOAP also has
some advantages:
Easy to consume - sometimes Rigid - type
checking, adheres to a contract Development tools For consuming web services,
its sometimes a toss up between which is easier. For instance Google's
AdWords web service is really hard to consume (in CF anyways), it uses SOAP
headers, and a number of other things that make it kind of difficult. On the
converse, Amazon's REST web service can sometimes be tricky to parse because
it can be highly nested, and the result schema can vary quite a bit based on
what you search for.
Which ever architecture you choose make sure
its easy for developers to access it, and well documented.
|
Understanding SOAP and REST Basics And Differences
Simple Object Access Protocol (SOAP) and
Representational State Transfer (REST) are two answers to the same question:
how to access Web services. The choice initially may seem easy, but at times it
can be surprisingly difficult.
SOAP is a standards-based Web services access
protocol that has been around for a while and enjoys all of the benefits of
long-term use. Originally developed by Microsoft, SOAP really isn’t as simple
as the acronym would suggest.
REST is the newcomer to the block. It seeks to
fix the problems with SOAP and provide a truly simple method of accessing Web
services. However, sometimes SOAP is actually easier to use; sometimes REST has
problems of its own. Both techniques have issues to consider when deciding
which protocol to use.
Before I go any further, it’s important to
clarify that while both SOAP and REST share similarities over the HTTP
protocol, SOAP is a more rigid set of messaging patterns than REST. The rules
in SOAP are important because without these rules, you can’t achieve any level
of standardization. REST as an architecture style does not require processing
and is naturally more flexible. Both SOAP and REST rely on well-established
rules that everyone has agreed to abide by in the interest of exchanging
information.
A Quick Overview of
SOAP
SOAP relies exclusively on XML to provide
messaging services. Microsoft originally developed SOAP to take the place of
older technologies that don’t work well on the Internet such as the Distributed
Component Object Model (DCOM) and Common Object Request Broker Architecture
(CORBA). These technologies fail because they rely on binary messaging; the XML
messaging that SOAP employs works better over the Internet.
After an initial release, Microsoft submitted
SOAP to the Internet Engineering Task Force (IETF) where it was standardized.
SOAP is designed to support expansion, so it has all sorts of other acronyms
and abbreviations associated with it, such as WS-Addressing, WS-Policy,
WS-Security, WS-Federation, WS-ReliableMessaging, WS-Coordination,
WS-AtomicTransaction, and WS-RemotePortlets. In fact, you can find a whole
laundry list of these standards on Web Services Standards.
The point is that SOAP is highly extensible,
but you only use the pieces you need for a particular task. For example, when
using a public Web service that’s freely available to everyone, you really
don’t have much need for WS-Security.
The XML used to make requests and receive
responses in SOAP can become extremely complex. In some programming languages,
you need to build those requests manually, which becomes problematic because
SOAP is intolerant of errors. However, other languages can use shortcuts that
SOAP provides; that can help you reduce the effort required to create the
request and to parse the response. In fact, when working with .NET languages,
you never even see the XML.
Part of the magic is the Web Services
Description Language (WSDL). This is another file that’s associated with SOAP.
It provides a definition of how the Web service works, so that when you create
a reference to it, the IDE can completely automate the process. So, the
difficulty of using SOAP depends to a large degree on the language you use.
One of the most important SOAP features is
built-in error handling. If there’s a problem with your request, the response
contains error information that you can use to fix the problem. Given that you
might not own the Web service, this particular feature is extremely important;
otherwise you would be left guessing as to why things didn’t work. The error
reporting even provides standardized codes so that it’s possible to automate
some error handling tasks in your code.
An interesting SOAP feature is that you don’t
necessarily have to use it with the HyperText Transfer
Protocol (HTTP) transport. There’s an actual specification for using SOAP over Simple Mail Transfer Protocol (SMTP) and there isn’t any reason you
can’t use it over other transports. In fact, developers in some languages, such
as Python and PHP, are doing just that.
A Quick Overview of
REST
Many developers found SOAP cumbersome and hard
to use. For example, working with SOAP in JavaScript means writing a ton of
code to perform extremely simple tasks because you must create the required XML
structure absolutely every time.
REST provides a lighter weight alternative.
Instead of using XML to make a request, REST relies on a simple URL in many
cases. In some situations you must provide additional information in special
ways, but most Web services using REST rely exclusively on obtaining the needed
information using the URL approach. REST can use four different HTTP 1.1 verbs
(GET, POST, PUT, and DELETE) to perform tasks.
Unlike SOAP, REST doesn’t have to use XML to
provide the response. You can find REST-based Web services that output the data
in Command Separated Value (CSV), JavaScript Object Notation (JSON) and Really
Simple Syndication (RSS). The point is that you can obtain the output you need
in a form that’s easy to parse within the language you need for your
application.
As an example of working with REST, you could
create a URL for Weather Underground. The API’s
documentation page shows an example
URL of http://api.wunderground.com/api/Your_Key/conditions/q/CA/San_Francisco.json.
The information you receive in return is a JSON formatted document containing
the weather for San Francisco. You can use your browser to interact with the
Web service, which makes it a lot easier to create the right URL and verify the
output you need to parse with your application.
Deciding Between
SOAP and REST
Before you spend hours fretting over the
choice between SOAP and REST, consider that some Web services support one and
some the other. Unless you plan to create your own Web service, the decision of
which protocol to use may already be made for you. Extremely few Web services,
such as Amazon, support both. The focus of your decision often centers on which
Web service best meets your needs, rather than which protocol to use.
Soap Vs Rest
SOAP is definitely the heavyweight choice for
Web service access. It provides the following advantages when compared to REST:
§ Language, platform, and transport independent
(REST requires use of HTTP)
§ Works well in distributed enterprise
environments (REST assumes direct point-to-point communication)
§ Standardized
§ Provides significant pre-build extensibility
in the form of the WS* standards
§ Built-in error handling
§ Automation when used with certain language products
REST is easier to use for the most part and is
more flexible. It has the following advantages when compared to SOAP:
§ No expensive tools require to interact with
the Web service
§ Smaller learning curve
§ Efficient (SOAP uses XML for all messages,
REST can use smaller message formats)
§ Fast (no extensive processing required)
§ Closer to other Web technologies in design
philosophy
Locating Free Web
Services
The best way to discover whether SOAP or REST
works best for you is to try a number of free Web services. Rolling your own
Web service can be a painful process, so it’s much better to make use of
someone else’s hard work. In addition, as you work with these free Web services
you may discover that they fulfill a need in your organization, and you can
save your organization both time and money by using them. Here are some to
check out:
One common concern about using a free Web
service is the perception that it could somehow damage your system or network.
Web services typically send you text, not scripts, code, or binary data, so the
risks are actually quite small.
Of course, there’s also the concern that Web
services will disappear overnight. In most cases, these Web services are
exceptionally stable and it’s unlikely that any of them will disappear anytime
soon. I’ve been using some of them now for five years without any problem.
However, stick with Web services from organizations with a large Internet
presence. Research the Web service before you begin using it.
Working with the
Geocoder Web Service
To make it easier to understand how SOAP and
REST compare, I decided to provide examples of both using the same free Web
service, geocoder.us (thank you to Mark Yuabov for suggesting it). This simple Web
service accepts an address as input and spits out a longitude and latitude as
output. You could probably mix it with the Google Maps API example I present in
“Using the Google Maps API to Add Cool Stuff to
Your Applications.”
Viewing a Simple
REST Example
Sometimes, simple is best. In this case, REST
is about as simple as it gets because all you need is an URL. Open your
browser—it doesn’t matter which one—and type
http://rpc.geocoder.us/service/csv?address=1600+Pennsylvania+Ave,+Washington+DC
in the address field. Press Enter. You’ll see the output in your browser in CSV
format:
You see the latitude, followed by the
longitude, followed by the address you provided. This simple test works for
most addresses in most major cities (it doesn’t work too well for rural
addresses, but hey, what do you expect for free?). The idea is that you
obtain the latitude and longitude needed for use with other Web services. By
combining Web services together with a little glue code, you can create really
interesting applications that do amazing things in an incredibly short time
with little effort on your part. Everyone else is doing the heavy lifting. You
can also test your REST API with simple to use tools like SoapUI.
Explaining a Simple
SOAP Example
SOAP, by its very nature, requires a little
more setup, but I think you’ll be amazed at how simple it is to use.
Begin this example by creating Windows Forms
application using Visual Studio. The sample code uses C#, but the same
technique works fine with other .NET languages (you’ll need to modify the
code to fit). Add labels, textboxes, and buttons as shown here (the
Latitude and Longitude fields are read-only).
Here’s where the automation comes into play.
Right click References in Solution Explorer and choose Add
Service Reference from the context menu. You’ll see the Add Service
Reference dialog box. Type the following address into the address field:
http://rpc.geocoder.us/dist/eg/clients/GeoCoder.wsdl and click Go.
Type GeocoderService in the namespace field. Your dialog box should look like
the one shown here.
Click OK. Visual Studio adds the
code needed to work with Geocoder in the background.
At this point, you’re ready to use the Web
service. All you need to do is to add some code to the Get Position button as
shown here.
private void btnGetPosition_Click(object sender, EventArgs e)
{
// Create the client.
GeocoderService.GeoCode_PortTypeClient Client =
new GeocoderService.GeoCode_PortTypeClient();
{
// Create the client.
GeocoderService.GeoCode_PortTypeClient Client =
new GeocoderService.GeoCode_PortTypeClient();
// Make the call.
GeocoderService.GeocoderResult[] Result =
Client.geocode(txtAddress.Text);
GeocoderService.GeocoderResult[] Result =
Client.geocode(txtAddress.Text);
// Check for an error result.
if (Result != null)
{
// Display the results on screen.
txtLatitude.Text = Result[0].lat.ToString();
txtLongitude.Text = Result[0].@long.ToString();
}
else
{
// Display an error result.
txtLatitude.Text = "Error";
txtLongitude.Text = "Error";
}
}
if (Result != null)
{
// Display the results on screen.
txtLatitude.Text = Result[0].lat.ToString();
txtLongitude.Text = Result[0].@long.ToString();
}
else
{
// Display an error result.
txtLatitude.Text = "Error";
txtLongitude.Text = "Error";
}
}
The code begins by creating a client. This is
a common step for any Web service you use with Visual Studio (or other
environments that support SOAP natively). To see another version of the
same step, check out the PHP example.
After you create the client, you use it to
call one of the methods supported by the Web service. In this case, you
call geocode() and pass the address you want to work
with. The result of the call is stored in a GeocoderResult variable
named Result. A single address could possibly end up providing multiple
positions if you aren’t specific enough, so this information is passed back as
an array.
Let’s assume that no errors occur (resulting
in a null return value). The example assumes that you provided great
information, so it places the information found in the first Result entry into
the Latitude and Longitude output. So, this example isn’t really that
complicated compared with REST, but as you can see, even a simple example is
more work.
The Bottom Line:
When To Use SOAP Or REST
Some people try to say that one process is
better than the other, but this statement is incorrect. Each protocol has
definite advantages and equally problematic disadvantages. You need to select
between SOAP and REST based on the programming language you use, the
environment in which you use it, and the requirements of the application.
Sometimes SOAP is a better choice and other times REST is a better choice. In
order to avoid problems later, you really do need to chart the advantages and
disadvantages of a particular solution in your specific situation.
There’s one absolute you should get from this
article. Don’t reinvent the wheel. It’s amazing to see companies spend big
bucks to create Web services that already exist (and do a better job than the
Web service the company creates). Look for free alternatives whenever possible.
In many cases, the choice of Web service also determines your choice of
protocol.
Actually there are two. Whether you pick
between SOAP or REST for your web service, making sure you thoroughly test your
APIs. Ready! API has a full suite of functional, performance, security and
virtualization tools for your API testing needs. You can also learn how to test RESTful APIs, in our API Testing Resource Center.
