What if you have a web product you want encourage 3rd parties to integrate with? Easy, you make it programmable using web services. But what kind? There are JSON-RPC, and REST/JSON and REST/XML and SOAP. I tend to prefer JSON-RPC and REST/JSON for internal integration between my own components. But when I write in .NET, either client in Silverlight or service in ASP.NET, I am all in with SOAP. Why?
SOAP is XML and XML is verbose, if compared with JSON. SOAP schema id verbose on its own right. It is also very complex. JSON-RPC and REST/JSON are simple, succinct, easy to implement even without any framework. Messages are easy to parse and process, that is cheaper to host and easier to scale. That is why I choose REST/JSON internally.
SOAP however is great for IDE integration. SOAP is so well formalized, in fact, well defined to be formalized, that tools support SOAP integration with ease. This is expecially true for .NET and Java.
Derive a class in Visual Studio from certain base, add some methods, mark them with an attribute, you got a SOAP web service.
Include a remote Web Service as if it was a local library, provide the URL to it, and presto, you have object browsing and code intellisense, as if it was a local library and local objects.
That is why to lure developers in Java (the most popular programming language at the moment) and C# and VB (to other popular languages) I feel the need to expose my web services as SOAP as well as REST/JSON
And let me confess, when I develop my server side as ASP.NET or Servlets, SOAP would probably be my first choice. Nowadays I tend to choose Python/Django, so my first choise is REST/JSON. But let me assure you I don’t forget to quickly follow up with SOAP alternative.
If you’d agree that eventually having both flavors (or all flavors if you really need 3rd parties supporting your product) is necessary, the question is, how does this knowledge changes your design of the API.
I shall dedicate a post to it in the future.
Filed under: Blogroll
