RPC/Encoded vs Document/Literal SOAP Styles

SOAP web services rely on Web Services Description Language (WSDL) bindings to define how messages are constructed, formatted, and validated over the network. The two primary style/use combinations historically used in SOAP services are RPC/encoded and Document/literal. This article breaks down the fundamental differences between these two messaging designs, examining their underlying mechanics, XML validation, interoperability standards, and why Document/literal has become the modern industry standard.

Understanding Style and Use

A WSDL binding defines two distinct attributes within the <soap:binding> and <soap:body> elements: * Style (RPC vs. Document): Determines the overall structure of the SOAP <Body>. * Use (Encoded vs. Literal): Determines how data types are serialized and whether the message payload adheres strictly to an XML Schema (XSD).

Combining these attributes yields different formats, with RPC/encoded and Document/literal representing two opposing philosophies in distributed systems.

What is RPC/Encoded?

In an RPC/encoded service: * Style (RPC): The SOAP <Body> contains an XML element named directly after the operation (method) being invoked. Inside this element are child elements corresponding directly to each method parameter. * Use (Encoded): Data is serialized according to the SOAP encoding rules (defined in Section 5 of the SOAP 1.1 specification). Type definitions are embedded directly in the message using attributes like xsi:type, rather than referencing a standalone XML Schema definition (XSD).

Example Payload Structure:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:typ="http://example.com/types">
   <soapenv:Body>
      <typ:GetCustomerDetails>
         <customerId xsi:type="xsd:int">101</customerId>
      </typ:GetCustomerDetails>
   </soapenv:Body>
</soapenv:Envelope>

Key Characteristics: * Tightly Coupled: Tightly maps to Remote Procedure Call programming models where the XML payload mirrors function signatures. * Non-Validating: Because it uses abstract encoding rules instead of explicit XSD definitions, standard XML parsers cannot validate the payload directly with an XSD schema. * Legacy Status: Not compliant with the WS-I (Web Services Interoperability) Basic Profile. It has been largely phased out due to interoperability bugs across different programming platforms.

What is Document/Literal?

In a Document/literal service: * Style (Document): The SOAP <Body> contains a complete, independent XML document. There is no requirement for the root element inside the body to match a specific method name. * Use (Literal): The XML payload is serialized “literally” against a predefined XML Schema (XSD) defined in the WSDL’s <types> section.

Example Payload Structure:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Body>
      <GetCustomerRequest xmlns="http://example.com/schemas">
         <customerId>101</customerId>
      </GetCustomerRequest>
   </soapenv:Body>
</soapenv:Envelope>

Key Characteristics: * Loosely Coupled: Focuses on business documents and data contracts rather than method invocations. * Fully Schema-Validatable: The payload can be validated directly by standard XSD validation engines before application logic processes it. * WS-I Compliant: Fully supported by the WS-I Basic Profile, ensuring seamless interoperability across Java, .NET, Python, and other platforms.

Key Differences

Feature	RPC/Encoded	Document/Literal
Primary Concept	Direct method invocation (RPC)	Arbitrary XML message exchange
Type Definition	SOAP encoding rules (Section 5)	XML Schema Definition (XSD)
XSD Validation	No standard validation against XSD	Strict validation against XSD
WS-I Compliance	Not compliant (WS-I BP 1.0 prohibited)	Fully compliant
Interoperability	Low (divergent vendor implementations)	High (consistent cross-platform support)
Performance	Slower (runtime type mapping required)	Faster (streamable, native XML parsers)

The Document/Literal Wrapped Pattern

A common variation of Document/literal is the Document/literal wrapped pattern. Standard Document/literal does not require the operation name to appear in the XML body, which can make method routing ambiguous on the server side.

The wrapped pattern resolves this by defining an XSD wrapper element that matches the operation name exactly. This provides the best of both worlds: the programmatic clarity of RPC (knowing the exact method name from the root element) combined with the strict XSD validation and WS-I compliance of Document/literal.