Rather than fueling the debate, Peter crystallized the benefits REST that can be directly used in SOAP world: - Model your system as a set of resources. (This way you’ll be able to address them and work with them independently of the root SOAP interface) - Assign logical URLs to resources. (Practically speaking, use URI strings as oppose to oblique Ids to refer to things) - Define schemas for resource representations. (Now that a resource can be addressed via a URI, clients will also need access to WSDL) - Enable discoverability of resources. (Allow traversal of SOAP “content”) - Provide appropriate resource manipulation operations. (Define a small set of operations clients can assume are supported)
It was a great talk, and one that I listened to with keen interest. This is definitely the direction we've been leaning towards with Groove Web Services. The coolest thing would be to allow for full traversal of the whole Groove data hierarchy via a Spider so that I could Google search my Groove spaces. But Alexis does point out that one would need to get the wsdl associated with a URI because you don't really know the interface behind it. Except of course that it could (should) have a GET binding for SOAP 1.2 someday, in which case the interface is "GET" and as long as you can identity the result as having a URI in it you can just keep issuing "GET" on those.
One advantage that people have claimed about REST is that it can take advantage of caching, but its debatable whether or not this really makes sense in a Web Service. I guess like everything else - it depends. The other big issue I have is security and authentication. Groove is a secure environment, and once we open it up with SOAP we want to retain that. So we will need to send along some authentication information with a GET, effectively requiring POST.
