REST or SOAP?
REST is acronym for Representational state transfer (REST). It is a software architecture style for distributed computing system such as Web.
Lost VMs or Containers? Too Many Consoles? Too Slow GUI? Time to learn how to "Google" and manage your VMware and clouds in a fast and secure HTML5 App.
For whatever reason, it got so popular today that many people equals the future of Web Services to REST. It’s true that REST based API is easy to understand with simple HTTP request/response messages in XML format. You can get some work done using text editor plus web browser.
But REST does NOT scale. When the programming model behind the API gets complicated, it cannot easily handle the complexity because REST is more a style than a spec for designing an API. It does not offer a systematic way defining the interfaces like WSDL for SOAP. All the interface descriptions are in text, meant for consumption by human, not for software tool. Some REST API provides XML schemas for the request/response messages, which is a step forward but not enough.
Having said that, REST is still a good style for a simple API and intended to be used with scripting languages like PHP.
Now, what is the rescue for a complicated API? I think SOAP is a much better choice than REST there.
Although SOAP, with its sophisticated WSDL, seems much more complicated than REST, but that is only for human. For the computer, WSDL is easy to handle. Good news is most developers don’t need to read WSDL. They can rely on tools to generate stub code for developing applications. While working on the high performance Web Service Engine, I had to read the WSDL for code generator because the AXIS does not perform well; otherwise I shouldn’t have had to neither.
By its very nature, SOAP is procedural and does not support OO programming. If you want to implement OO, you have to design the interfaces very much like the OO code in C, where you have the struct as object while every function has a pointer to the struct. Even it’s doable in some way, but it doesn’t look natural at all, especially when you use the stubs in real OO languages like Java. That is where VI Java API comes to help.
In general, OO is the choice of modern APIs. But SOAP does not support OO. You can see the gap there. The gap is not so noticeable today as most SOAP APIs are simple, too far away from the complexity of VIM API. It might change in the future. By then, an extended SOAP with OO support will surface and bridge the gap.
Technically supporting OO in SOAP is not big deal. We already have a successful implementation in VI Java API. The key is to extend the WSDL to include the type definition (class) beyond the functions (method). As lack of type information, the managed object model is coded manually in VI Java API.