Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Interactions between the SOAP API and plugins ======

**RFC: this page is a request for comments, nothing is set in stone**

===== Current status =====

The SOAP API currently does not accept any contributions from plugins, the plugins contributes fields or methods. The main reason is that the plugins do not have meaningful hooks which they can use to contribute safely to the SOAP API.

===== Constraints =====

SOAP API clients are usually sensitive to changes in the format of the data they receive, so the mechanism for plugins contributing additional fields to the SOAP output must either be backwards compatible or a one-time change which can accomodate multiple plugins.

===== Possible mechanisms =====

==== Wrapping plugin fields as custom fields ====

The SOAP API already has support for custom fields, which describe fields in terms of data types and validation . Plugins can declare for the SOAP API and other possible APIs the type of fields they expose. These fields can then be processed by SOAP API clients and submitted back.

==== Declaring custom methods ====

The SOAP API can register capabilities on behalf of the plugins. A base installation of MantisBT 1.2.6 with no plugins will have the capabilities [Core = 1.2.6 ] . Including version 1.0 of the TimeTracking plugin will mean that the capabilities are [Core = 1.2.6, TimeTracking = 1.0]. We will also provide means for the plugins to declare custom methods which will then be invoked by the SOAP clients.

A client is expected to know what methods and fields are exposed by a certain capability. While the Core capability will be documented by the WSDL, the plugin-declared capabilities - dynamic by nature - will not be exposed using WSDL and their correct usage will be enforced by the plugins.