README

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

Features

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

Provides a proxy module allowing javascript code served by an eZ Publish server to execute cross-domain webservice calls (without resorting to jsonp or html tricks) and even cross-protocol calls

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 :-)

Prerequisites

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 make ajax calls to the server itself using the integrated javascript library the ezjscore extension is recommended. Any other javascript library for xmlrpc/ jsorpc can also do.
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

Basics

Server (eZPublish exposes webservices):

to receive xmlrpc, jsonrpc or 'rest' calls, you need to:
1. modify the configuration in wsproviders.ini and possibly in site.ini.append.php
2. create a file extension/<xxx>/<jsonrpc|xmlrpc|rest>/initialize.php with the php code to be exposed as webservice
3. manage access control to the exposed services via the administration interface and/or configuration settings

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 wsproviders.ini
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.

Known limitations

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). Currently:
- 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

FAQ

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.

gggeek / ggwebservices

Maintainers

Details

README

Features

Prerequisites

Basics

Known limitations

FAQ