routing design

[jdamme]

Hello,
I would like to discuss the routing implementation.
Currently it uses the method as key, but i think this is not preferred.

I made minimalistic implementation using the path as key (https://github.com/jdamme/swurf)

If you define a resource but you ask for an unsupported method it should return Method Not Allowed.
I think this is difficult to achieve with the current design. Would you consider something like this?

[DEGoodmanWilson]

Interesting, yes, keying the routers on paths could help with automatically generating 405 responses. I would certainly be open to considering a PR that implemented this behavior!

[jdamme]

The only thing that I'm worried about is the performance when adding a larger amount of routes.
Currently I match chunk per chunk, I would prefer a single regex per resource, but I want to avoid undefined greedy regex matches ofc.

On another note:
Is the use of the named option pattern really worth it? Personally I think it makes the server header hard to read?
I see no real advantage over simple setters on the server. I was expecting to find all the settings for the server under the config header, instead I found some macros and option functions under the server.
Also when setting an option it is immediately push_back into a vector of options, What If I give 2 times the same option?

These are just thoughts, I'm not trying to be a d*ck. ETR also has a fairly good implementation around libmicrohttpd, but I don't really understand his directory structure which makes the code hard to understand. Have you looked at that implementation or others?

Maybe we could all work together on a project?
It just seems better to work on 1 great C++ embedded web/restserver instead of each developer rolling their own version, which seems to happen a lot in C/C++ development.

[DEGoodmanWilson]

The named option pattern was an excuse for me to have fun. I really like the way it works with CPR, but the invocation model is a bit different in that library. Originally, there was no explicit start() method in Luna, so all options had to be passed into the constructor, but that's since changed.

Anyway, I don't really write the header files for legibility. My highest priority for making the library usable is writing good documentation.

You ask: What if you pass the same option twice? In truth, I'm not sure. MHD lets you do that, but in all honesty, I don't know what happens then. A nice thing to have would be to find a way to make passing in an option multiple times cause a compiler error…would need to think on how to make that work. Or at least throw a runtime exception, which is less ideal, but certainly better than allowing undefined behavior.

I'm not sure what ETR is…can you provide a link? I'm not really familiar with any other C++ wrappers for MHD. I haven't researched this space well, as Luna originated from a very specific need at one of my previous companies, and I continue to develop it, because I continue to use it in a variety of projects.

[DEGoodmanWilson]

Oh wait I remember the other reason that most of the options are in the constructor: I didn’t want the caller to be able to change any of them after the server had been started, because those changes would have been no-ops. Could also make them parameters to start() and achieve the same effect I think. Anyway wanted to reinforce that they should be set once before the server started.

[jdamme]

These are 2 libs I researched for wrapping MHD:
https://github.com/etr/libhttpserver
https://github.com/ufal/microrestd

I think both are decently written. Just small things didn't feel right. For libhttpserver the directory structure makes no sense to me and for microrestd the flow just seems off. It calls handle on a request etc. I think it makes more sense to pass a request to a router or dispatcher and get a reponse like you are doing.

Another 2 implementations that are really good:
https://github.com/oktal/pistache
https://github.com/datasift/served
but they are based on asio, the hello world example is like 2MB which was to high for my needs.
I wanted to make an implementation that doesn't rely on any external libs apart from MHD.
Even using c++17 features seems a bit troublesome if you want to write a lib that can be used by a lot of people.

I dunno, I feel the world needs a standard GoTo C++ lightweight web/rest server :-) haha

[DEGoodmanWilson]

I dunno, I feel the world needs a standard GoTo C++ lightweight web/rest server :-) haha

I couldn't agree more :D I don't want to require anything beyond what is strictly necessary, and MHD is, while far from perfect, delightfully lightweight. I want the syntax to be lightweight as well-my maxim is that it should be easy to use correctly, and difficult to use incorrectly. I fall short of the mark, I think, but I think I do better than most.

Anyway, if you like where Luna is heading, help is always welcome! There's still ever so much to do…