GG Webservices extension for eZ Publish
An extension that adds/improves the native capabilities of eZ Publish to work as
- webservices server
- webservices client
with a visual webservices debugger thrown in for good measure
Allows to easily execute calls to remote servers using JSONRPC, XMLRPC and SOAP protocols or REST schemes (both from within php code and templates)
Allows to expose existing functionality as JSONRPC or XMLRPC, REST and (better than eZ native) SOAP webservices, similar to what can already be done with SOAP and eZJSCore in any eZ Publish installation
Allows to expose functionality as webservice regardless of the protocol used by the client - without having to duplicate code
Allows easy debugging of webservice calls by providing a complete graphical interface for debugging
Adds support for WSDL in SOAP calls (both server-side and client-side)
Improves the existing http client adding features such as support for more authentication schemes, compressed requests etc...
Allows usage of JSONRPC or XMLRPC (and eventually SOAP) to call functions exposed via the ezjscore extension API
Keeps the same API as the existing eZP SOAP classes for maximum interoperability
And much more :-)
- PHP 5 / eZP 4.0+
- to execute/receive jsonrpc calls, the php JSON extension is needed
- to execute/receive rest calls, the php SIMPLEXML or JSON extensions are needed
- to execute/receive xmlrpc calls, the php XMLRPC extension is needed
- to call remote services using wsdl descriptions the php SOAP extension is needed
- to integrate with the ezjscore extension, eZP 4.2 is needed (and the ezjscore extension too, of course)
- to receive soap/xmlrpc/jsonrpc/rest+post calls from users authenticated via the standard session mechanism (such as e.g. ajax calls), the ezformtoken extension has to be disabled
Server (eZPublish exposes webservices):
- to receive xmlrpc, jsonrpc or 'rest' calls, you need to:
- modify the configuration in
wsproviders.iniand possibly in
- create a file
extension/<xxx>/<jsonrpc|xmlrpc|rest>/initialize.phpwith the php code to be exposed as webservice
- manage access control to the exposed services via the administration interface and/or configuration settings
- modify the configuration in
Client (eZPublish accesses webservices exposed by other systems):
- every remote webservice server that has to be accessed from the eZ Publish
server itself has to be defined in
- to call remote webservices from within templates use the template fetch function
fetch( 'webservices', 'call', hash( paramname, value, ... ) )Please remember to desactivate the view cache where needed for node templates that execute webservice calls
- to call remote webservices from php code use
ggeZWebServicesClient::call( $server, $metod, $params=array(), $options=array() );
For more details on usage of the extension, look in the doc/ directory.
- support for WSDL is limited, as is support for SOAP 1.2
- jsonrpc support is only available for version 1.0, not for 2.0
- the ws client does not support automatic cookie management
- the ws client does not support oauth authentication
- the proxy view works exposing an xmlrpc+jsonrpc api. This means that it can not be used to emulate the richer semantics of soap/rest calls. E.g. at the moment it can not be used to send POST calls to upstream rest webservices
- rest support is far from perfect, as the extension was developed based on rpc
semantics (call a method which takes a hash of parameters).
- for the rest client, the parameters will be translated into query string or http request payload, not into a slash-separated part of the url.
- for the rest server, there is no support for having slash-separated parameters or complex routing rules
- and much more: read doc/todo to get a detailed list of bits which could improve
Q: how do I debug webservices without going insane?
A1: you're a lucky guy, since this extension provides a nice graphical debugger within the standard admin interface
A2: when DebugSettings/DebugOutput and TemplateSettings/DevelopmentMode are both enabled, the requests sent by the fetch function webservices/call will be displayed as part of the standard debug output
A3: by enabling logging, you n00b! There is an ini setting in wsproviders.ini that controls verbosity for a log file dedicated to webservices: var//log/webservices.log
Q: how secure is this extension?
A: the main author prides himself with being an extremely security-focused developer - he learnt many things about webservices and security in the infamous "lupii worm" incident, and later even worked as security consultant for a short time. Having said that, the codebase is by now quite large, and the amount of functionality available staggering. There is no guarantee whatsoever, either implicit or explicit, that using it will not expose your data, or data of your customers, to fraudulent use. If this poses a problem to you, please sponsor a security audit.