We are creating an API that suits the benefits of a REST based architecture. However where I struggle is in how easy it is to consume from different technologies.
Its a c# WCF service and if consuming via c# is a doddle, 1) give the dll with the contract to the calling project 2) use the WebChannelFactory generic to wrap the contract before calling the url and method.
However given this is an API I want other non .net based systems to be able to interract with it. The argument I hear is that why should developers read all the documentation for the REST based service, manually create a http request (in their language of choice), and then parse the response. When if we created a web service using SOAP all they would have to do is add a reference to it and let their technology of coice build the call and response objects for dealing with the SOAP and make the call using a few lines of code (I know its this easy in c# and apparently java is easy too).
Seems like from a consumption perspective from differing technologies that support SOAP and building references from WSDL’s that SOAP wins hands down. But I really want to use REST just have this argument and I cant really argue with it.
I have only ever seen one argument for SOAP in favor of REST that I completely agree with, and your question makes it: Use SOAP if that is what the client/customer/user wants. If it really is the case that all of the consumers of this service can more easily use SOAP, then you should go with that.
Of course, if you want to support a client platform that does not have built-in support for SOAP, that could be another matter. You don’t want your client/customer/user building a SOAP client layer from scratch, unless you just really don’t like them.