| [higgins-dev] Re: Notes from IRC about IdAS REST |
|
Here are some thoughts about enhancements to the XDI CP we think will make it so we can use it. We could discuss these on the call today.
1. Client Side:
The IContext needs a way to "setRemoteContextURL" and "setMessageFormat". Jim has previously proposed generic methods for setting properties which could be used: setProperty( String strPropertyName, Object propertyValue). We discussed doing this through configuration settings, but that doesn't seem to be quite right because configuration settings end up being shared by every instance, whereas properties are per-instance. We would like to be able to set the following properties on an XDI CP:
ctx.setProperty( "RemoteContextURL", "https://wag.bandit-project.org/AuthenticatedSession/xxxxxxx/idas");
ctx.setProperty( "MessageFormat", "XML or JSON or whatever");
The purpose of the "RemoteContextURL" is to provide the prefix to the URL that identifies the context. The XDI CP would append to that URL whatever else it needs (subnouns, query params, etc.) for any given operation it is asked to perform. We would like to review those, as we will need to document them for our users. Perhaps some of them should be settable with other setProperty calls.
We have some suggestions about the XML and JSON format that we would like to see. It may be that we need more than the single property of "MessageFormat" to set. Also, we feel that the XDI CP should, as much as possible, request multiple attributes at a time for an entity, instead of just one at a time. Same for updating. Update messages should be sent only when the applyUpdates method is called - which may mean that the content of the PUT (or POST) contains updates for multiple entities and/or attributes.
2. Server Side:
On the server side, our server application would handle the incoming URL and lookup the IContext - using the URL that was set in the client-side in the "RemoteContextURL" property. It is assumed that the full URL would have additional stuff appended as needed by the client side, as illustrated below:
The "stuffAppendedByClientSideXDICP" would be handed to a handler method provided on the server side that knows how to interpret it and perform the specified action. This handler would also receive the HTTP method, HTTP headers, and HTTP content so it would know what to do. The headers, content, and method would be whatever the client side XDI CP had set. Here is an example of what this method might look like:
/**
* The server application calls this method to handle IdAS request that came from the client side XDI CP.
* @param ctx This is the context that our server application looked up using
* the https://wag.bandit-project.org/AuthenticatedSession/xxxxxxx/idas part of the URL. This is the context this method
* should use to process the request.
* @param relativeURL This is the rest of the URL that was set by the client side XDI CP - in the example above
* it is the "stuffAppendedByClientSideXDICP" string.
* @param httpMethod This contains the HTTP method (POST, PUT, GET, DELETE) that was called.
* @param request From this parameter, the method can get the HTTP headers and content.
* @param response Using this parameter, the method can send a response back to the client. */ handlerObject.handleRequest(
IContext ctx,
String relativeURL,
int httpMethod,
HttpServletRequest request,
HttpServletResponse response);
>>> "Markus Sabadello" <msabadello@xxxxxxxxxxxxx> 6/25/2008 4:13 AM >>>
- Daniel/Tom/Jim need an IdAS REST interface for one of their projects. Markus has been working on something like that (the higgins.idas.xdi component, which can expose Higgins contexts as XDI endpoints) - In XDI, REST is achieved on a logical level: The kind of operation you perform on a resource depends on the predicates of an XDI message ($get, $del, $add, $mod). These messages are all HTTP POSTed. For a more traditional HTTP REST approach, the server should also accept all HTTP commands ("verbs"), with the resource being encoded in the url ("noun"). For example: If you want to delete Markus' e-mail address, you would POST the following XDI message to http://graceland.parityinc.net/xdi-idas/context =sender $del / =(uid=saba,dc=parityinc,dc=net) +(http://www.eclipse.org/higgins/ontologies/deployment/idas/basic/ldap#attr_mail) The more traditional approach would be to do an HTTP DELETE on http://graceland.parityinc.net/xdi-idas/context/=(uid=saba,dc=parityinc,dc=net)/+(http://www.eclipse.org/higgins/ontologies/deployment/idas/basic/ldap#attr_mail) Markus says this can be done but has a few disadvantages (url length/encoding, just one operation per round-trip). - The IdAS REST server can output the results of a $get / HTTP GET operation in any of the XDI serialization formats. Daniel would prefer the output not to look like XDI (for example use real URIs instead of URIs-cast-to-XRIs). Markus says the internal format of the server should still be XDI, but a different serialization format could be defined and implemented that makes the output look more traditional. - Daniel/Tom/Jim just need basic IdAS functionality (read, add, modify entities and attributes). They don't need schema, access control, etc. - The IdAS REST server is currently a standalone application that maps URLs to Contexts according to its configuration. Daniel says they need more control over the URL space, dynamically assign URLs to Contexts, etc. The way to do this is to embed the IdAS REST server in their application rather than have it run in standalone mode. - Regarding the client side, Daniel/Tom/Jim would like to use the XDI CP to talk to the XDI endpoint. - We're going to have a call about this today at 9 MDT. Markus |