Comments (1)

REST or SOAP?

REST is acronym for Representational state transfer (REST). It is a software architecture style for distributed computing system such as Web.

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.

Author: Steve Jin is the author of VMware VI and vSphere SDK (Prentice Hall), creator of VMware vSphere Java API. For future articles, please subscribe to RSS or Email, and follow on Twitter.

Comments (1)

Happy new year! A new posting is way overdue after I set up the blog early last December.

Today, we surpassed 5,000 downloads. This is an important milestone for the project as it indicates the adoption of this powerful yet easy-to-use API has reached a new level.

Moving forward, the API will continue to evolve with new vSphere releases. This is, of course, a very basic requirement. At the same time, it will support other VMware solutions like SRM, maybe LabManager, that have Web Services. VMware SRM QA team has done initial porting of the high performance Web Service engine to work with SRM in their testing framework, and observed 15 times performance boost over Apache AXIS engine.

As enterprises transforms to private cloud computing model, vSphere plays even more important role there. To simplify the learning curse of leveraging vSphere for the cloud, I will investigate a reduced version of VI Java API that matches the concept model of vCloud API. It means it will only expose DataCenter, VirtualMachine these basic types that a Cloud developer will care about, but not HostSystem and other types that only concern data center operators. This reduced API may require some pre-configuration, for example, the inventory tree is structured in a certain way that are best for faciliating cloud computing. This fits the trend “Convention over Configuration” that Ruby On Rail brought in years ago. This is investigative than anything else. I will update my finding along the way.

Author: Steve Jin is the author of VMware VI and vSphere SDK (Prentice Hall), creator of VMware vSphere Java API. For future articles, please subscribe to RSS or Email, and follow on Twitter.