RejectedSoftware Forums

On Wed, 04 Nov 2015 06:58:53 GMT, Brad Anderson wrote:

There was some talk about this on the forums before but I didn't really see an answer.

I can't use SessionVar (it only works with the web interface) and the REST interface generator doesn't seem to allow using HTTPServerRequest/Response parameters like the web interface generator does so I can't access a session that way. I saw some stuff about using @before but I don't understand how that would help (@before doesn't appear to be documented that I can see).

The REST interface generator is generally designed to enforce the RESTful aspects of the interface as far as possible. Since REST requests are supposed to be state-less, sessions are not directly supported.

However, you could (ab)use the @before attribute to get the desired effect:

class RestIntf {
    @before!getSession("session")
    void test(Session session)
    {
    }
}

Session getSession(HTTPServerRequest req, HTTPServerResponse res)
{
    return req.session ? req.session : res.startSession();
}

But this sounds like we should put some effort into fully supporting JSON based routes in the web interface generator. Return values of type Json are already supported, but not much more than that.

Am 05.11.2015 um 05:44 schrieb Brad Anderson:

On Wed, 04 Nov 2015 08:07:18 GMT, Sönke Ludwig wrote:

The REST interface generator is generally designed to enforce the RESTful aspects of the interface as far as possible. Since REST requests are supposed to be state-less, sessions are not directly supported.

However, you could (ab)use the @before attribute to get the desired effect:

[snip]

One problem I hit trying this was that serveRestJSClient requires an interface (without the session argument) and the implementation of the interface doesn't match the signature because of the additional argument from @before. Not sure if there is a way around this.

A trick that is usually possible is to make the session argument have a
default value (= Session.init) and put it in the interface like that.
The catch is that default and Nullable parameters are not properly
handled by the JS client, yet. I'll open a ticket for that.

However, thanks to JavaScript's handling of undefined values, it
actually does work for the special case of POST requests + default
parameters.

But this sounds like we should put some effort into fully supporting JSON based routes in the web interface generator. Return values of type Json are already supported, but not much more than that.

That would be nice.

Also nice would be some sort of authentication scheme for the REST stuff. I'm new to REST and nobody seems to agree on how this should be done but tokens seem to be popular. OAuth, too, of course.

Definitely. It needs some thought how to make it as generic as possible
without losing the semantic information that is necessary for applying
it to the various targets (e.g. the JS client).

For now I think I'll move back to the Web interface to get around these issues.

Someone in the IRC channel mentioned userman. The Readme says "A major revision of the source code is currently underway. More instructions will be added in that process." Does that mean it's not ready for any sort of use yet? I don't mind breaking changes as my use case is extremely simple.

If it's just for storing user information in a database and handling
simple password authentication, the latest "stable" version should be
fine (it's also used by some other projects, such as vibenews). The
version that is in the works adds things like a user/group management
web frontend and a RESTful internal API to be able to share the same
user management server between multiple services. It has some limited
API breakage, but the DB upgrade is supposed to happen smoothly.