ArcGIS REST vs. SOAP API

This is a good question. While I like REST, I don't see a way to request Z and M values for geometries. It looks like this is possible with SOAP using the PointN object. It would be great to see this question evolve to list more differences.

Another factor is what clients you need to support - if it's just Silverlight, then SOAP is a lot more attractive.

I've developed SOE's and GP services that send complex objects via Json.NET. These objects are easily consumed by Silverlight, but it looks like a javascript client will have a much harder time.

REST - Representational State Transfer

REST basically means that each unique URL is a representation of some object. You can get the contents of that object using 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).

SOAP - Simple Object Access Protocol

SOAP is mostly used for Enterprise applications to integrate wide types and no. of applications and another trend is to integrate with legacy systems, etc. Google is consistent in implementing their web services using SOAP (except Blogger)

SOAP wins with GeoProcessing with ArcGIS Server +1 for Kirk

At a previous clients, we looked at this for ages and the long and the short of it, for them, was that SOAP has too much development lead time, and REST was easy for an organisation to implement.

It cna be argued SOAP aren't actually web services too...

Here's some arguments for you:

SOAP/REST