Use this wiki plugin to pull data from any JSON or SOAP enabled web service, e.g. those from Yahoo, or opendata portals based on CKAN.
Parameters
Display remote information exposed in JSON or YAML or SOAP XML Introduced in Tiki 3. Go to the source code Preferences required: wikiplugin_webservice
Parameters
Accepted Values
Description
Default
Since
(body of plugin)
Template to apply to the data provided. Template format uses smarty templating engine using
double brackets as delimiter. Output must provide wiki syntax. Body can be sent to a parameter instead by
using the bodyname parameter.
url
Complete service URL
3.0
params
Parameters formatted like a query: param1=value1&param2=value2
7.0
service
Registered service name.
3.0
template
For use with registered services, name of the template to be used to display the
service output. This parameter will be ignored if a body is provided.
3.0
bodyname
word
Name of the argument to send the body as for services with complex input.
Named service required for this to be useful.
3.0
Examples
Plugin Image
File is not an image.
The result is you can embed a webservice-specific plugin tag, with one named parameter
And even change the output format by defining the format in a block after the tag:
1.1. Why
This powerful plug-in allows you to bring external information in to Tiki easily. There are many contexts where existing legacy corporate systems or remote web sites contain useful information. This plug-in will allow you to display the information from these systems inside Tiki. It will allow administrators to set up information sources as easy and safe to use pre-configured wiki page plug-ins.
Some good examples of this are:
Including bug tracking information from an external source (such as Bugzilla) in documentation pages.
Showing the results of images searches in xxx where the results are automatically refreshed.
Displaying data from opendata portals as text, or in maps.
For a list of some of the web based information sources available have a look at, put URL here.
1.2. How
The Webservice plug-in consumes content from remote sites and customizes the way it is displayed.
The remote site must export the data in either JSON or YAML, or XML using SOAP.
The data must be publicly available as no authentication methods are currently supported.
There are multiple ways to display the information are supported, with various security and portability concerns.
Self-contained, all inline in a page
Defined (by an administrator) as a webservice
Defined (by an administrator) using a plugin alias.
The web service plugin is disabled by default. Also it is marked as unsafe, which means any use or modification requires validation by an administrator or a moderator with the required privileges.
1.3. Output types
The output can generate:
Smarty to generate wiki syntax
Smarty to generate HTML
Javascript to generate HTML
The most basic, and safest, way to display is to use Smarty templates to generate wiki syntax but using Smarty to generate HTML affords more flexibility.
no longer working
{WEBSERVICE(url="https://query.yahooapis.com/v1/public/yql?q=select%20*%20from%20weather.forecast%20where%20woeid%20in%20(select%20woeid%20from%20geo.places(1)%20where%20text%3D%22nome%2C%20ak%22)&format=json")}
{{$response.query.results.channel.item.title}}
{FANCYTABLE(head="Date|Day|High|Low")}
{{foreach from=$response.query.results.channel.item.forecast item=result}}
{{$result.date}}|{{$result.day}}|{{$result.high}}|{{$result.low}}
{{/foreach}}
{FANCYTABLE}
{WEBSERVICE}
1.6. Fuller Example
Note: this isn't such a good example because it doesn't work out of the box: you'll have to find your own bugzilla instance.
Copy to clipboard
{WEBSERVICE(url=http://bugzilla.example.com/bugexport.pl?id=00002345)}
!! {{$response.title}}
||ID|[http://bugzilla.example.com/bug/{{$response.id|escape|'url'}}|{{$response.id}}]
Status|{{$response.status}}
Assignee|{{$response.assignee.full_name}}
Open Date|{{$response.open_date}}
Last Modification|{{$response.last_modif}}
||
{{foreach from=$response.comments item=comment}}
* [http://bugzilla.example.com/bug/{{$response.id|escape|'url'}}#{{$comment.id}}|{{$comment.title}}] by ''{{$comment.author.full_name}}'' on {{$comment.date}}
{{/foreach}}
{WEBSERVICE}
1.7. Registering a Webservice
To use higher capabilities, such as HTML generation, a web service must be registered. A registered web service contains:
A name
A URL with parameters
A type (REST / SOAP)
A list of available templates
A template contains:
A name
The output format (use value tikiwiki or html)
The engine used to execute the template ( smarty or javascript )
The content of the template (this is not a content or smarty template, this template is defined where you register the webservice.)
When the output of Smarty is Tiki syntax, Smarty elements use double curly braces rather than single ones to avoid conflicts with the syntax.
To register web services, visit tiki-admin.php?page=webservices on your tiki installation.(this is also where you define the body of the template used, you cannot reference an allready defined content template)
A registered web service can be then called e.g. from a wiki page using the Webservice plugin:
A Plugin Alias can be created to hide complexity by making the web service aspects transparent. The end user sees it as a normal plugin but internally, it's only a reserved name. When encountered, the parameters provided to it are forwarded to an other plugin. Default values can be provided in the process.
For example, a BUGZILLA plugin could be created to access the bug information. This plugin would:
Redirect to the WEBSERVICE plugin
Always use bugzilla as the service
Accept a required id parameter which would be passed directly to WEBSERVICE
Accept an optional template parameter, which would provide the required documentation to indicate the supported templates (ex: status|link|short|complete). If not provided, it would use complete as the default value.
Ignore any user input in the body
Require no validation because all parameters are safe.
Plugin Alias can be used for other purposes than web services, like shortcut plugins to various tracker lists and item configurations.
To register plugin aliases, visit tiki-admin.php?page=plugins on your tiki installation.
1.9. Implementation notes
Other scripting languages or templating engines could be added. However, because Tiki is already bundled with Smarty, it was a natural choice.
1.10. Security
When including content from remote sites, the primary issue is that to get any kind of special formatting, the content from the remote host must be provided as HTML. One one side, HTML is difficult to manipulate and can hardly be included seamlessly inside the page. Content will always appear to be different. On the other hand, the consumer becomes vulnerable to XSS attacks because unwanted JavaScript may be included in the remote HTML.
The webservice strategy mitigates this risk by applying an age-old concept: separate data from presentation. The web services only request the data from the remote host and nothing of the presentation aspects. The consumer side is responsible to display the information using their preferred display method. In the case of Tiki, Smarty is default option. Before being sent to the template engine, the received data is filtered to avoid XSS coming from the data. The presentation layer is assumed to be audited and safe.
1.11. Presentation Suggestion
Even if security has to be insured, the remote host still is likely to know best how the content should be presented. Providers are encouraged to provide suggested templates to render the data. These templates can be audited by the site administrator to be used directly or serve as a sample to build custom templates.
The templates are to be provided as part of the body under the _template property.
The webservice registry presents the suggestions proposed by the remote hosts. These suggestions can be registered as valid templates.