path: root/Doc/lib/libxmlrpclib.tex

\section{\module{xmlrpclib} --- XML-RPC client access}

\declaremodule{standard}{xmlrpclib}
\modulesynopsis{XML-RPC client access.}
\moduleauthor{Fredrik Lundh}{effbot@telia.com}
\sectionauthor{Eric S. Raymond}{esr@snark.thyrsus.com}

% Not everyting is documented yet.  It might be good to describe 
% Marshaller, Unmarshaller, getparser, dumps, loads, and Transport.

\versionadded{2.2}

XML-RPC is a Remote Procedure Call method that uses XML passed via
HTTP as a transport.  With it, a client can call methods with
parameters on a remote server (the server is named by a URI) and get back
structured data.  This module supports writing XML-RPC client code; it
handles all the details of translating between conformable Python
objects and XML on the wire.

\begin{classdesc}{ServerProxy}{uri\optional{, transport\optional{,
                               encoding\optional{, verbose}}}}
A \class{ServerProxy} instance is an object that manages communication
with a remote XML-RPC server.  The required first argument is a URI
(Uniform Resource Indicator), and will normally be the URL of the
server.  The optional second argument is a transport factory instance;
by default it is an internal \class{SafeTransport} instance for https:
URLs and an internal HTTP \class{Transport} instance otherwise.  The
optional third argument is an encoding, by default UTF-8. The optional
fourth argument is a debugging flag.

The returned instance is a proxy object with methods that can be used
to invoke corresponding RPC calls on the remote server.  If the remote
server supports the introspection API, the proxy can also be used to query
the remote server for the methods it supports (service discovery) and
fetch other server-associated metadata.

\class{ServerProxy} instance methods take Python basic types and objects as 
arguments and return Python basic types and classes.  Types that are
conformable (e.g. that can be marshalled through XML), include the
following (and except where noted, they are unmarshalled as the same
Python type):

\begin{tableii}{l|l}{constant}{Name}{Meaning}
  \lineii{boolean}{The \constant{True} and \constant{False} constants}
  \lineii{integers}{Pass in directly}
  \lineii{floating-point numbers}{Pass in directly}
  \lineii{strings}{Pass in directly}
  \lineii{arrays}{Any Python sequence type containing conformable
                  elements. Arrays are returned as lists}
  \lineii{structures}{A Python dictionary. Keys must be strings,
                      values may be any conformable type.}
  \lineii{dates}{in seconds since the epoch; pass in an instance of the
                 \class{DateTime} wrapper class}
  \lineii{binary data}{pass in an instance of the \class{Binary}
                       wrapper class}
\end{tableii}

This is the full set of data types supported by XML-RPC.  Method calls
may also raise a special \exception{Fault} instance, used to signal
XML-RPC server errors, or \exception{ProtocolError} used to signal an
error in the HTTP/HTTPS transport layer.  Note that even though starting
with Python 2.2 you can subclass builtin types, the xmlrpclib module
currently does not marshal instances of such subclasses.

When passing strings, characters special to XML such as \samp{<},
\samp{>}, and \samp{\&} will be automatically escaped.  However, it's
the caller's responsibility to ensure that the string is free of
characters that aren't allowed in XML, such as the control characters
with ASCII values between 0 and 31; failing to do this will result in
an XML-RPC request that isn't well-formed XML.  If you have to pass
arbitrary strings via XML-RPC, use the \class{Binary} wrapper class
described below.

\class{Server} is retained as an alias for \class{ServerProxy} for backwards
compatibility.  New code should use \class{ServerProxy}.

\end{classdesc}


\begin{seealso}
  \seetitle[http://xmlrpc-c.sourceforge.net/xmlrpc-howto/xmlrpc-howto.html]
           {XML-RPC HOWTO}{A good description of XML operation and
            client software in several languages.  Contains pretty much
            everything an XML-RPC client developer needs to know.}
  \seetitle[http://xmlrpc-c.sourceforge.net/hacks.php]
           {XML-RPC-Hacks page}{Extensions for various open-source
            libraries to support instrospection and multicall.}
\end{seealso}


\subsection{ServerProxy Objects \label{serverproxy-objects}}

A \class{ServerProxy} instance has a method corresponding to
each remote procedure call accepted by the XML-RPC server.  Calling
the method performs an RPC, dispatched by both name and argument
signature (e.g. the same method name can be overloaded with multiple
argument signatures).  The RPC finishes by returning a value, which
may be either returned data in a conformant type or a \class{Fault} or
\class{ProtocolError} object indicating an error.

Servers that support the XML introspection API support some common
methods grouped under the reserved \member{system} member:

\begin{methoddesc}{system.listMethods}{}
This method returns a list of strings, one for each (non-system)
method supported by the XML-RPC server.
\end{methoddesc}

\begin{methoddesc}{system.methodSignature}{name}
This method takes one parameter, the name of a method implemented by
the XML-RPC server.It returns an array of possible signatures for this
method. A signature is an array of types. The first of these types is
the return type of the method, the rest are parameters.

Because multiple signatures (ie. overloading) is permitted, this method
returns a list of signatures rather than a singleton.

Signatures themselves are restricted to the top level parameters
expected by a method. For instance if a method expects one array of
structs as a parameter, and it returns a string, its signature is
simply "string, array". If it expects three integers and returns a
string, its signature is "string, int, int, int".

If no signature is defined for the method, a non-array value is
returned. In Python this means that the type of the returned 
value will be something other that list.
\end{methoddesc}

\begin{methoddesc}{system.methodHelp}{name}
This method takes one parameter, the name of a method implemented by
the XML-RPC server.  It returns a documentation string describing the
use of that method. If no such string is available, an empty string is
returned. The documentation string may contain HTML markup.  
\end{methoddesc}

Introspection methods are currently supported by servers written in
PHP, C and Microsoft .NET. Partial introspection support is included
in recent updates to UserLand Frontier. Introspection support for
Perl, Python and Java is available at the XML-RPC Hacks page.


\subsection{Boolean Objects \label{boolean-objects}}

This class may be initialized from any Python value; the instance
returned depends only on its truth value.  It supports various Python
operators through \method{__cmp__()}, \method{__repr__()},
\method{__int__()}, and \method{__nonzero__()} methods, all
implemented in the obvious ways.

It also has the following method, supported mainly for internal use by
the unmarshalling code:

\begin{methoddesc}{encode}{out}
Write the XML-RPC encoding of this Boolean item to the out stream object.
\end{methoddesc}


\subsection{DateTime Objects \label{datetime-objects}}

This class may initialized from date in seconds since the epoch, a
time tuple, or an ISO 8601 time/date string.  It has the following
methods, supported mainly for internal use by the
marshalling/unmarshalling code:

\begin{methoddesc}{decode}{string}
Accept a string as the instance's new time value.
\end{methoddesc}

\begin{methoddesc}{encode}{out}
Write the XML-RPC encoding of this DateTime item to the out stream object.
\end{methoddesc}

It also supports certain of Python's built-in operators through 
\method{_cmp__} and \method{__repr__} methods.


\subsection{Binary Objects \label{binary-objects}}

This class may initialized from string data (which may include NULs).
It has the following methods, supported mainly for internal use by the
marshalling/unmarshalling code:

\begin{methoddesc}{decode}{string}
Accept a base64 string and decode it as the instance's new data.
\end{methoddesc}

\begin{methoddesc}{encode}{out}
Write the XML-RPC base 64 encoding of this binary item to the out
stream object.
\end{methoddesc}

It also supports certain of Python's built-in operators through a
\method{_cmp__} method.


\subsection{Fault Objects \label{fault-objects}}

A \class{Fault} object encapsulates the content of an XML-RPC fault tag.
Fault objects have the following members:

\begin{memberdesc}{faultCode}
A string indicating the fault type.
\end{memberdesc}

\begin{memberdesc}{faultString}
A string containing a diagnostic message associated with the fault.
\end{memberdesc}


\subsection{ProtocolError Objects \label{protocol-error-objects}}

A \class{ProtocolError} object describes a protocol error in the
underlying transport layer (such as a 404 `not found' error if the
server named by the URI does not exist).  It has the following
members:

\begin{memberdesc}{url}
The URI or URL that triggered the error.
\end{memberdesc}

\begin{memberdesc}{errcode}
The error code.
\end{memberdesc}

\begin{memberdesc}{errmsg}
The error message or diagnostic string.
\end{memberdesc}

\begin{memberdesc}{headers}
A string containing the headers of the HTTP/HTTPS request that
triggered the error.
\end{memberdesc}


\subsection{Convenience Functions}

\begin{funcdesc}{boolean}{value}
Convert any Python value to one of the XML-RPC Boolean constants,
\code{True} or \code{False}.
\end{funcdesc}

\begin{funcdesc}{binary}{data}
Trivially convert any Python string to a \class{Binary} object.
\end{funcdesc}


\subsection{Example of Client Usage \label{xmlrpc-client-example}}

\begin{verbatim}
# simple test program (from the XML-RPC specification)

# server = ServerProxy("http://localhost:8000") # local server
server = ServerProxy("http://betty.userland.com")

print server

try:
    print server.examples.getStateName(41)
except Error, v:
    print "ERROR", v
\end{verbatim}