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, and 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 and Delicious.
APIs use 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
  APIs 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:
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 ColdFusion anyway), 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.
Whichever architecture you choose make sure its easy for developers
  to access it, and well documented.