On Wed, 20 Nov 2013 09:13:14 GMT, Sönke Ludwig wrote:

1) The main reason is that I would like to provide different media (ContentType) to people. So far, XML, JSON, HTML.
2) I'll also use ContentType over the URL-way for versioning (I'm aware of it's drawbacks).
3) And of course, I'd like to take full advantages of it by using objects / structs in the client, not return a string that I have to pass to another function.

So it looks like two additions to the REST system would be necessary: Allow to specify the serializer (JSON/XML/...) that is used, and allow to specify a custom suffix for each URL (".json"/".xml"/...). Then I'd imagine this to work in that scenario: 

router.registerRestInterface!JsonStringSerializer(..., ".json");
router.registerRestInterface!XMLStringSerializer(..., ".xml");
router.registerRestInterface!HTMLStringSerializer(..., ".html");

Of course, the XML and HTML serializers would also have to be written, but that's trivial.

An alternative option may be to expose some struct/class that controls serialization and writing data to response via @after so that it can be tweaked in any way on per-method basis. I have never thought much about this development direction when working on REST part so hard to make any good proposals at once but sounds like a reasonable feature set to support.

What I tried so far was mostly based on @before / @after attributes:

  • @before: handles the authen (and set others parameters based on the header, like the version), works like a charm;
  • @after: I tried to use it to set the format, but I need to return something (for 3), and it WILL be serialized. If I just write to HTTPServerResponse, my data get duplicated, so I needed to tell the framework how to do it. I first override toString(), which in turns called a delegate (toJson, toHtml, toXML), but no luck with that (doesn't get called?). I also thought of implementing a custom Json object, but it's a struct, so no inheritance, and that's really hacky.

Since the @before/@after feature is quite new, I didn't yet have the chance to actually try it out, so I'll defer an answer to later or to @Dicebot (who implemented it).

I don't think @after can be used here. It was designed to make any adjustments to returned value and/or additions to response HTTP. Use case of completely overriding default data output mechanism with own one simply did not come to my mind. It can probably be added relatively simply, hard part is design, not implementation.

It is awesome to hear this stuff actually works though! Because I had no time to actual use it in live project personally since have added it :)

I'm planning to rework the REST interface code a bit so that the MethodStyle is passed as a template parameter instead of as a runtime parameter (this would allow to shift a great amount of work from runtime to compile time and thus improve performance). I guess in that process it will be easy to also make the serializer a template argument. But I can't give an exact time schedule for this, yet.

Damn, I have kept being tempted to move it to template parameter since first changes to this module and resisted all the time because it seemed like intended choice :D