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

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.

One thing to think about is how query parameters will be handled in this case. Currently all primitive types are directly converted to string (e.g. 2.5 gets param=2.5) and complex parameters get serialized to JSON (e.g. SomeStruct(2.5, "hello") might get param={"field1":2.5,"field2":"hello"}). XML or HTML might be less practical here. But JSON isn't optimal either, so maybe there is something entirely different that could be used here instead.

Will it then be possible to use all the "normal" server features then (I'm thinking about render here) ?
I also quite don't get the custom suffix. The server will use the same resources, represented in different way. So I would rather go for a predicate that get the HTTPServerRequest and tells if the registered interface + serializer couple can handle the request.
But then the order or registration should matter, or there should be a way to set the default event handler (because if I'm asked for a wrong version / ContentType, I want to answer with a 415, not a 404). For this part I don't know what's already buit in Vibe, but I guess there's something ?

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.

Good to know! Well after experimenting a bit, I think I will stay out of vibe.http.rest for the server, even if it gets strong foundations, it will get in my way for my use case. I'll go back at it when I switch to the client part. I'll try to give a feedback here when the job is done. Feel free to email me if I can be of any help.

Usually you wouldn't want that, but it was the most natural choice for
the case when someone declares a complex parameter for a GET method.
Another possibility would be to break up the struct into multiple
parameters (e.g. param_field1=2.5&param_field2=hello), but then there
are possible ambiguities and the implementation complexity grows
considerably.

It seemed odd to me too, but then I thought how funny it would be to have associative array with classes as key and values. Maybe provide a way to have a simple parameter schema is there is no struct / AA / classes involved (only 'scalars' and arrays) ?

On Wed, 20 Nov 2013 13:59:33 GMT, Dicebot wrote:

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.

[...]

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 :)

Yup I know, I was just trying to see if I can hack my way to make it do what I want it to do. Turns out I couldn't. The design seems quite neat to me, I was able to use @before to provide an UserContext to my function (so far, only authnz), and @after's goal was quite clear. The only issue was it's not on the API doc on the site.