Okay, I know that all of this are not strictly versus each other, but I used to find the combination of options for SOAP messages intimidating. Why so many options to essentially accomplish the same thing? The following are the basic options:
- rpc/literal
- rpc/encoded
- document/literal
- document/encoded
Since encoded is not part of the WS-I (Web Service Interoperability) standard, that just leaves rpc/literal and document/literal. So, you can just use the former for request/response RPC type calls, and the latter for passing business documents, right? Wrong!
In actuality, the rpc vs. document is misleading as you can make rpc-style calls with either underlying representation.
The default and most commonly used is document/literal. The underlying WSDL will be more complicated, but WSDL is not supposed to be for humans (so they say). The rpc style is limited to very simple XSD types such as String and Integer, and the resulting WSDL will not even have a types section to define and constrain the parameters.
Far more complicated typing is allowed with document. This is because the document style also comes with an XSD that can be used to validate the incoming SOAP messages; if you use rpc you will not have an XSD to validate against. However, the rpc style’s SOAP messages are easier to look at and understand.
The wrapped variant (used with document), which is a de facto standard, helps to address this. It re-arranges the SOAP message some so that it is easier to understand from the programmer’s view and looks more like rpc. It clearly identifies the service operations and the names of each parameter. The downside is that the client code you have to write is a little more complicated to put together.
In the end, document/literal/wrapped is the default in Java’s web services.
