Here's a WSDL file for Zimbra's Admin SOAP API.

Updates

• 22 August 2007
  • added CreateDomainRequest operation
  • implemented complexTypes ldapRecord, accountRequest, domainRequest to support different definitions of the same element name in different contexts (this actually DRY'd the schema)
• 20 August 2007
  • changed urn:zimbra schema in the WSDL so that account & domain elements always ref a common element (fixed/simplified to avoid redefinition of an element name)
• 16 August 2007
  • revised this post to explain & support my findings about Zimbra's SOAP API
• 15 August 2007
  • expanded coverage of WSDL with many more Zimbra Admin operations
  • refactored types/schema to reuse element definitions via ref attribute
  • implemented simpleContent string for sessionId & a
  • moved header context into the 'zimbra' namespace
• 04 August 2007
  • now with support for the several app-level methods
  • also fixed some namespace problems

This WSDL for Zimbra does not fulfill WSDL's true purpose: to make Zimbra's SOAP services immediately consumable. Ideally, WSDL enables mapping remote services to native objects without writing adapter code.

The fact is that Zimbra's SOAP API does not fit elegantly into WSDL's ideal.

Zimbra's SOAP interface wraps the content of every message

Every message body is wrapped in an operationNameRequest or operationNameResponse element. Yet the WSDL specs say,

Multiple part elements are used if the message has multiple logical units

Zimbra goes the route of monolithic messages. Though not functionally critical, this extra level in the SOAP message causes mapping to unique complexType *Request & *Response objects in the client, instead of directly to part-level simpleType & complexType elements. Direct mapping to usable message parts enables very slim adapter code (if any) in the client.

Also, the Zimbra's method names follow the pattern operationNameRequest instead of the normalized, simple operationName, adding further complexity to the WSDL.

Zimbra's web API is not RESTful

A sessionId must be propagated through each request & updated if changed in a response. Also, an initial AuthRequest gets an AuthToken, and subsequent requests' headers must contain that token.

Nonetheless

WSDL rocks as a way to generate stubs for your own implementation of a web service.

Read the rest of this entry