If you implement REST Web Services, you want to secure them. The simplest approach is to use the basic authentication () with user name and password. To protect all the resources behind the REST APIs, you can simply implement filter as introduced in Java Servlet 2.3 ().
As a software professional using Java since its very beginning, I have been following the case regarding Google’s using Java APIs in its Android OS. I don’t want to repeat what has happened so far because you can find these updates by searching the Internet. All I want to say is that the case is pretty educational not only on the technology itself but also on the legal side like patents, copyright.
It’s a known bug in VI Java API that it did not escape strings to be included within a XML tag. The potential risk, although very very rare, is that it can blow the de-serialization of a request on the server side. I did get one or two reports on failing on login, which turned out to be caused by special characters like < or > in passwords. As a quick fix, an escaping logic has been added to escape the special characters in passwords.
As a software professional, you may have heard about the source compatibility and binary compatibility. With the Web Services, a new type of compatibility came up. This is what I call wire compatibility. It’s not related to the programming but the XML messages passed on the wire. Since we don’t use XML directly but programming APIs, the wire compatibility surfaces and affects the source and binary compatibility.
Too abstract? You bet. Let’s pick up an example here. Because VMware vSphere API is defined in WSDL, I will use it in the following discussion.
In vSphere 4.1, the method PowerOnMultiVM_Task() gets an additional parameter called option typed as OptionValue array. The following are related parts in the WSDL:
<operation name="PowerOnMultiVM_Task"> <input message="vim25:PowerOnMultiVM_TaskRequestMsg" /> <output message="vim25:PowerOnMultiVM_TaskResponseMsg" /> <fault name="RuntimeFault" message="vim25:RuntimeFaultFaultMsg"/> </operation> <complexType name="PowerOnMultiVMRequestType"> <sequence> <element name="_this" type="vim25:ManagedObjectReference" /> <element name="vm" type="vim25:ManagedObjectReference" maxOccurs="unbounded" /> <element name="option" type="vim25:OptionValue" minOccurs="0" maxOccurs="unbounded" /> </sequence> </complexType>
As you can see, the minOccurs of the option element is zero, meaning it’s optional. If you have an application built with 4.0 (no option parameter by then), the SOAP request still works. So it’s compatible on the wire.
Some of the troubles come from the disconnect between conventional programming model and that of vSphere API. In this blog, I summarize the top 5 myths about vSphere API based on my experience and the questions I see in the VMware community forum and vSphere Java API forum:
- Non-existing Managed Objects
- Pervasive PropertyCollector
- Short-Lived Task Object
- “Weak” HostSystem
- “Un-documented” View
Let’s examine each of them one by one.
Today I read a posting at VMware community forum about the weird code required by C# Web Service. If the following line is missing, then the vSphere API call to get properties doesn’t work:
VimApi.VimService.PropertySpec.allSpecified = True
So, where does the allSpecified come from? and why is it needed?
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.