SOAP Web Services
SOAP is a protocol specification for exchanging information using XML over an application layer protocol, e.g. HTTP, providing a messaging framework which web services can be built. SOAP is platform and language agnostic as its messaging format is simply a XML document containing specific elements as defined by specification. Exposing Java SOE’s as SOAP web services allows your SOE to be self-contained and self-described allowing its functionality to be interoperable among disparate consumers. Just as you can expose your Map Server Object as a Web Service with a WSDL endpoint your SOE exposed as a Web Service will have a WSDL endpoint.
REST Web Services
Representational state transfer (REST) is a pattern that takes advantage of a stateless client-server architecture whereby web services are resources and can be consumed by their URL’s. The design for REST is intended to simplify the web service architecture by implementing constraints in parallel with the HTTP protocol, although not exclusively limited to HTTP.
Considerations for exposing SOE as SOAP vs. REST Web Service
- REST
- You intend for your web service to be consumed by ArcGIS Web API's, e.g. JavaScript or Flex.
- The SOE service and client have a shared understanding of the context and content being exchanged. Since there is no formal web service interface description, both clients and servers must understand the data being exchanged.
- Web service delivery into an existing web site. REST web services allow for easy integration using technologies like AJAX to consume the service.
- SOAP
- You intend for your web service to be consumed by the Web ADF.
- A formal contract must be defined for consumers. SOAP web services have WSDL endpoints which describes messages, operations, bindings, and location of the web service.
- You intend for your web service to interact in an enterprise level distributed computing system.