(perspective provided by Google)
Google believes in a vibrant ecosystem of devices, utilities and third parties exchanging energy information and we believe that a data exchange based on REST is the best way to achieve that environment.
Keep It Simple (KISS)
A. Light-weight.
B. Implementation is easy, lowering barrier to entry.
C. Does not require any expensive tooling or dev tools to implement -- leveling the playing field.
D. The elements above create a platform-agnostic world, leading to rapid inter-operability --- since it's easy for developers to create solutions on diverse platforms, interop is a must, and it happens.
REST is a better protocol for data, and for ADE we are dealing with data.
Proven Security
End-to-end security. If TLS (Transport Layer Security) is good enough for financial transactions it is likely good enough for OpenADE.
Proven to work for both device to business and business to business communication Because REST is simpler and more efficient than SOAP (for both hardware and network resources) , it is much easier to use RESTful interfaces in a larger variety of applications. For example, we have proof by example that a RESTful interface can be used to securely transfer ADE style data from devices
(http://www.theenergydetective.com/ted-5000-overview.html) to Google (http://code.google.com/apis/powermeter/). This exact same RESTful interface is used to securely send ADE style data from utilities to Google (http://sites.google.com/site/powermeterpartners). Example implementations are available from a variety of companies including Google via GData (http://code.google.com/apis/gdata/) as well as Microsoft via OData (http://www.odata.org/).
Finally, a RESTful protocol offers a number of advantages over SOAP, and all of these advantages come from fully using the features of HTTP. The first advantages come from using distinct methods (GET, PUT, POST, DELETE, etc) and separate URIs for the resources you are interacting with.The advantage is that the method and URI travel in the HTTP request headers and can be seen by intermediaries. Those intermediaries can do a variety of things, like saving bandwidth via caching, or aid in debugging via logging, or load balancing by passing requests along to different servers based on the request. All of those features are available today with off the shelf HTTP proxies and reverse proxies such as Squid. Other HTTP features like etags, gzip, and caching can save a tremendous amount of bandwidth, particularly important if you are connecting networks of 10s or 100s of thousands of devices. Gzip allows responses to be compressed, saving bandwidth by sending less bytes, and etags act like a response fingerprint, allowing a device to return a completely empty body response if a resource has not changed since it was last requested. Finally caching can also save bandwidth by avoiding round trips on the network. All of these mechanisms are available to a RESTful protocol, and can be utilized by off the shelf infrastructure like proxies, reverse proxies, and caches, all of which incorporate the lessons learned building the World Wide Web over the past 20 years.
By having less redundancy and complexity via a single interface for utilities and for third parties planning to interact with devices, we believe that using a RESTful interface for ADE will allow for a much more vibrant and diverse energy monitoring and management ecosystem.
From Wikipedia (http://en.wikipedia.org/wiki/Representational_State_Transfer):
SOAP RPC over HTTP, on the other hand, encourages each application designer to define a new and arbitrary vocabulary of nouns and verbs (for example getUsers(), savePurchaseOrder(...)), usually overlaid onto the HTTP 'POST' verb. This disregards many of HTTP's existing capabilities such as authentication, caching, content type negotiation, etc. and may leave the application designer re-inventing many of these features within the new vocabulary. Examples of doing so may include the addition of methods such as getNewUsersSince(Date date),savePurchaseOrder(string customerLogon, string password, ...).
From O'Reilly's recently released "RESTful Web Services Cookbook":
HTTP is an application-level protocol that defines operations for transferring representations between clients and servers. In this protocol, methods such as GET, POST, PUT, and DELETE are operations on resources. This protocol eliminates the need for you to invent application-specific operations such as createOrder, getStatus, updateStatus, etc. How much you can benefit from the HTTP infrastructure largely depends on how well you can use HTTP as an application-level protocol. However, a number of techniques including SOAP and some Ajax web frameworks use HTTP as a protocol to transport messages. Such usage makes poor use of HTTP-level infrastructure.