0 Votes

XClams API Design Documentation

Last modified by Ludovic Dubost on 2012/01/14 10:45

The XClams velocity apis are available in similar format as JavaDoc.

The working draft of the Curriki REST API is also available.


In curriki there are three levels of APIs that will be used:

  • Plugins
    • These provide access via the xwiki object ($xwiki.pluginname in velocity)
  • Custom Classes
    • These provide specialized classes for documents (pages) and possibly (to be tested) objects
  • Servlets
    • These provide external access points to be used by other applications (including Javascript AJAX calls)


The initial focus will be to provide only the functionality required to complete the EOU 1 phase of development.

  • A servlet will be needed to provide the needed wrappers for the internal APIs (currently targeting Add Path functionality only) that are needed for AJAX and other external applications
  • A plugin (AssetManager) will be needed to provide general access to functions that are not directly related to a page (such as creating an asset)
  • A custom class (org.curriki.xwiki.plugin.asset.Asset) will be needed to provide asset level functions, which should probably use object level custom classes for the various types of assets


  • The Asset servlet should be used instead of using wiki pages to provide the functionality of editing and updating asset metadata and rights. 
  • The Asset Servlet should provide a REST-style API for both Java script interfaces in the application and as a generalized web services interface to transact with resources in the repository. The interfaces should be extended over time to meet this objective.
  • Discussions with partner are commencing to define the syntax and parameters for this generalized we service API. This will be extended from the JSON interfaces created in V1.6 for the Add path. 

Proposed Use Cases with Partners

  • Partner Member to submit content that would also be added (shared) with Curriki and perhaps other repositories.
  • Partner Member can search for content on Curriki while on partner site
  • Partner Member links to (embeds a copy of) content
  • Partner Member copies content to partner site
  • Curriki (and Partner?) Member can delete their content while on partner site
  • Curriki (and Partner?) Member can create content on Curriki and push it to partner site

_Please define "Member" in this context._ Curriki Member, or Partner Member?

_Feel free to correct my attempt at defining Curriki vs Partner Members_

Proposed Extensions to Support Partners

  • Single Sign On
    • Requires
      # Distributed Identity Management/Authentication
      # Authorization
    • Possible services used
      # Local
      # OpenID
      # OpenSSO
      # SAML
      # Shibboleth
      # WS-Federation
      # PAPI
      # CAS
  • Copy resource
    • Is this like export ?
  • Link to resource
    • In what regard? The page name is already a "link".
      • I think of a resource link more as embedding (via SWF or javascript code) like a YouTube video or a Delicous.com Tagcloud. The original resource is always hosted by curriki, but can be displayed on partner sites.
  • Get a Resource
    • What type of format?
    • Can you clarify between copy & get?
  • Post a Resource from a partner site
    • Can be done now with add path. What is different here?
  • Delete a Resource from a partner site
  • Search resources from a partner site
    • Is this different than the new search?
      • Search via an API so that partner sites can create a tool that searches curriki content.

Meeting Notes

This wiki is licensed under a Creative Commons 2.0 license
XWiki Enterprise 12.10.5-node2 - Documentation