[Building Sakai] Questions about developing a new websrvice for Sakai...

[Gregory Guthrie]

We are in process to create a new webservice for Sakai, which would allow one to access pre-defined report data automatically and remotely. The overall goal is to allow one to define the desired data using standard Sakai tools, but then have the data easily available externally and programmatically for further analysis, including integration of data from various Sakai report sources.

That means that to get any report data, you can user this URL:
         http://localhost:8080/report/siteID/reportName.format
where format can be xml, csv, xls or json

In doing this we found a few limitations, and want to check if these are a correct approach to the problem and understanding on how things work in the Sakai infrastructure, or if there are any better ways or suggestions.

1) We wanted to data to be available in xls and csv formats also since those are such simple formats to import (we setup some Excel reporting tools). However the current Rest API only supports to send xml and json formats to browser/client (Output formats). The REST API implementation in sakai is such that we can restrict the extensions they support, but we cannot add support to extra formats such as csv and xls format as well. And also there is no way to set the Content-Type header in implementation classes as well.

That meant that we could not use the standard /direct/... API standard for our new webservice, which would seem like a better interface.

2) this led to a secondary problem, to provide authentication for these requests. From our developer:
"In sakai platform all requests are going through the service "direct".  We created a new service, which is independent of direct service. If we use Sakai's REST implementation then it will come to our entity broker implementation through "direct" service, so there will be no extra coding for authentication. 
Even-though I used "sakai-login" tool to implement authentication and used the attribute "sakai.tool.helper.done.url" to set the original url path who invokes the login request, but after user gets authenticated, I am not getting the correct value for the attribute "sakai.tool.helper.done.url" . So I am not able to redirect the request to the original url which invokes this login operation."

Because of this we would have to either allow unauthorized access to the data, or implement a separate authorization mechanism.

3) We also had a problem with an uncaught exception is site-stats; requiring us to modify
  sitestats-components\WEB-INF\components.xml  
      (This is a temporary fixup for a JIRA problem, should go away when that is fixed.)
        https://jira.sakaiproject.org/browse/STAT-350

To remedy this we created a short-term fix by patching the components.xml file:
		<!-- Server Event Registry -->
		<property name="serverEventIds" ref="org.sakaiproject.sitestats.api.serverevents.List" />
		
		<!-- Sakai services -->
		...
		<property name="checkLocalEventNamesFirst" value="true"/>
	</bean>
           <bean id="org.sakaiproject.sitestats.api.serverevents.List" class="java.util.ArrayList">
		<constructor-arg>
      		<list>
        		<value>site.add</value>
        		<value>site.del</value>
        		<value>user.add</value>
        		<value>user.del</value>
        		<value>user.login</value>
      		</list>      
    	</constructor-arg>
  	</bean>

-------------------------------------------