On Thu, 26 Mar 2015 14:31:58 GMT, Mathias LANG wrote:

On Thu, 26 Mar 2015 10:38:51 +0100, Sönke Ludwig wrote:

Am 26.03.2015 um 10:05 schrieb Mathias LANG:

Now that 2.067 is out, I will resume my work on the new REST generator. That's definitely something that could fit in.
Do you need the attributed parameter in addition, or do you just want to do some kind of check (like isAuthenticated) ?

Still, the question is if it's a good idea to pack this as a feature
into the REST generator. I don't want it to become too complex and
it's already quite far in that regard.

BTW, I think this went past me, what's new in the new generator?

Complex in terms of code, or complex in terms of use ?

More in terms of API complexity. Implementation complexity is rather high, too, of course, but that's another matter. But sine we have @before:, I think we can safely stop thinking about any extensions in this direction.

The new generator is still an experiment, and I expect a lot of discussions ;)

Here's an example on how you would use it: 

import std.stdio, std.traits;

struct Context { string ip; }

interface MyAPI { void test(); }

class MyAPIImpl : RESTServer!(MyAPI, MyAPIImpl) {
override:
        void test(HTTPServerRequest ctx) {
                writeln(ctx.ip);
        }
}

// In the client
void main() {
        auto c = new RestInterfaceClient!MyAPI();
        c.test();
}

This allow to get a context (HTTPServerRequest / HTTPServerResponse) without relying on @before. It is also supposed to allow you to create more complete use case / framework on top of it, but that last part needs more though.

Note: It will only be available with 2.067, because compilers bugs.

To be frank, I really dislike that approach. The nice thing about the current approach where the HTTP part is almost completely hidden from the service implementation is that it can be used locally, too. With this change, you'd basically always have to use a REST connection to talk to it, even if just locally from the same process. It also makes it very easy to break the REST idiom by looking at req.session or similar (at least you have to jump through some hoops to do that now).