REST & ODWEK

[Justin Derrick]

Has anyone built a solution using REST with ODWEK?  I'm curious to hear from anyone who has some experience doing this.

-JD.

[Alessandro Perucchi]

Not yet :-) in my To Do list.

But I know my colleagues at IBM US Services team have done a REST interface to ODWEK.
But more than that I don't know.

[Justin Derrick]

Yeah, my understanding is that RESTful apps are supposed to be 'stateless', which doesn't lend itself to working with ODWEK, which has states like 'logged in' and such.  I'm not sure how authentication would be handled at all -- and without authentication, you can't do things like queries or retrievals.

Maybe the key is to build an intermediate layer that has a persistent connection to ODWEK, and implements a RESTful interface to the upstream system.

This is all a little outside the realm of what I do on a daily basis -- so any discussion would be enlightening.  :)

-JD.

[Alessandro Perucchi]

What I was thinking was to have a login at first before going the REST service.

Then the session information will be kept somewhere (cookie/...) and then when the user wants to do some actions, then either a login will happen (each time...) (take a long time)
or there is a connection pool created with generic technical user
or there is there is several connection pool per "user group"

When the login is done, and the user is associated with a connection, then you can do something "stateless".

At least it is in this direction I'm thinking to go...

[RizwanK]

REST doesn't led to "session-ing" and this is very true for other apps as well that to RESTful interactions, not just ODWEK. I have done implementations where, as Alessandro mentioned, you retain the UUID in a cookie and supply that as part of each request.

Another approach that could work with REST is to restrict the access to the endpoints via a List of IP addresses that this service can respond to i.e. internal network subnet address or a range of IP addresses. When a request comes in, the service can verify against the internal list (stored in DB somewhere to allow for changes without code deployment). If the IP address exists allow the request otherwise return a HTTP-403 (forbidden).

Good discussion though and definitely has me tempted to do a prototype against our implementation.

[TTP4RFGrL3Ki]

I've created a REST client for ODWEK. Of course, first a login has to be done.
The REST URL contains the user name because folder visibility depends on user access rights.

If you have any specific questions, please let me know.

Andreas

[Alessandro Perucchi]

One question, why do you need the username in the URL? Should that part be in the current session?
And once you are logged in, then, you cannot change your permissions... so I don't see the need to have this info in the URL.

or am I missing something?

[TTP4RFGrL3Ki]

You're right, it's not really necessary to have the user name in the URL.
The reason was simply to get always the same results (e. g. list of folders) with the same URLs.
However, this decision is just a matter of taste and doesn't make a real difference. (and could easily be changed since the REST API is not yet delivered to customers)

Btw.: I created the REST API with Jersey and have an interface that allows to select if ODWEK should be accessed directly or via REST. The small ODWEK proxy running on Tomcat allows to develop on platforms not supporting ODWEK like OS X without having to debug remotely.

[Alessandro Perucchi]

Ahhhhhhhhhh I see your point :-) Thank you for the explanation!

That means also that a URL is valid only for a user, and cannot be "shared". I am more thinking about documents that are available without special permissions/restrictions.