When is it appropriate to use the ArcGIS Server REST API vs. the SOAP API and vice-versa? What do you see as the advantages of one over the other?

For example, the SOAP service can be consumed as a Service Reference to integrate into Visual Studio. Is there anything available that would give you that level of integration with REST?

More info: ArcGIS GIS Services

  • 3
    If you want to cancel a gp job, you'll currently need to use SOAP. Commented May 11, 2011 at 14:04

5 Answers 5


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

  • I think "Simple" is a misnomer in SOAP (except maybe when clicking through a VS wizard to do it). It seems easier to use REST, but ultimately it depends on what clients you need to support (like Kirk said above).
    – Bratch
    Commented May 14, 2011 at 0:31
  • 2
    Google has only five SOAP APIs, and 45 REST APIs: programmableweb.com/apis/directory/…
    – scw
    Commented May 17, 2011 at 4:29

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:



You can now Cancel jobs and return Z and M as of ArcGIS REST API 10.1

Submit GP Job (now with option to returnZ and returnM)

Cancel GP Job


More and more people are moving towards REST services as they are very easy to use and code while SOAP is very thik and slow compared to REST. In Near future we will see big migration and (Hopefully) SOAP will DIE

  • 1
    More and more people are moving to services that they think are RESTful but actually aren't
    – nmtoken
    Commented Mar 5, 2016 at 10:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.