| \section{\module{xmlrpclib} --- XML-RPC client access} |
| |
| \declaremodule{standard}{xmlrpclib} |
| \modulesynopsis{XML-RPC client access.} |
| \moduleauthor{Fredrik Lundh}{fredrik@pythonware.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\optional{, |
| allow_none}}}}} |
| 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. If \var{allow_none} is true, |
| the Python constant \code{None} will be translated into XML; the |
| default behaviour is for \code{None} to raise a \exception{TypeError}. |
| This is a commonly-used extension to the XML-RPC specification, but isn't |
| supported by all clients and servers; see |
| \url{http://ontosys.com/xml-rpc/extensions.html} for a description. |
| |
| Both the HTTP and HTTPS transports support the URL syntax extension for |
| HTTP Basic Authentication: \code{http://user:pass@host:port/path}. The |
| \code{user:pass} portion will be base64-encoded as an HTTP `Authorization' |
| header, and sent to the remote server as part of the connection process |
| when invoking an XML-RPC method. You only need to use this if the |
| remote server requires a Basic Authentication user and password. |
| |
| 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). |
| The primary acess to the content of a \class{Binary} object is |
| provided by an attribute: |
| |
| \begin{memberdesc}[Binary]{data} |
| The binary data encapsulated by the \class{Binary} instance. The data |
| is provided as an 8-bit string. |
| \end{memberdesc} |
| |
| \class{Binary} objects have the following methods, supported mainly |
| for internal use by the marshalling/unmarshalling code: |
| |
| \begin{methoddesc}[Binary]{decode}{string} |
| Accept a base64 string and decode it as the instance's new data. |
| \end{methoddesc} |
| |
| \begin{methoddesc}[Binary]{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} |