Am 29.09.2015 um 07:26 schrieb Sebastiaan Koppe:

In general I appreciate the method of constructing an Interface and a derived Class for modeling rest endpoints. But there were some frictions I had, including:

1) Unable to set/read headers manually since HTTPServer(Request|Response) is not available. E.g. for CORS or manual cache-headers, reading custom headers, branch on Accept header etc.

Have you seen the @headerParam annotation? It lets you map a single
parameter to a single header field. As of 0.7.25 it also supports ref
and out parameters to write to the response object.

2) I want to run some code before some endpoints. But @before requires your function to emit a value that gets inserted into the endpoint's function. Current workaround is registering a catch-all route - router.any("*", &doYourStuff);. But that is obviously too much.

Do you have an example for this? I'm asking because ideally a solution
for this would be agnostic to the underlying HTTP transport. One of my
goals for this system is that the implementation class is also usable
using direct D calls (i.e. not only by using the RestInterfaceClient!T
as a proxy).

3) I have a rest endpoint that needs to return a generated XML file.

We just need to decide on a design for this, as the original
implementation was targeted at a pure JSON based protocol. Some possible
(non-exclusive) approaches:

  • Support OutputStream parameters and @contentType annotations,
    similar to the web interface generator. This is mainly useful for
    returning large binary data blobs (files), but would lose static typing
    in the D interface.
  • Recognize XMLDocument as a return type. This would solve cases
    where only a few routes would return XML.
  • Implement general support for XML as an alternative to JSON (decide
    based on "accepts" header.
  • Make formats other than JSON pluggable (i.e. pass custom
    serialization routines that work on paramters and return values in some
    way).

4) Proper CORS pre-flight handling.

This makes it impossible for me to use vibe.web.rest.

This is indeed bad to be missing in some situations (of course it can be
worked around manually, but that's a bit besides the point of the
interface generator). There is an open issue
(#546) for this.

If you'd like to lend a hand, this would probably be the best candidate.
It should be relatively straight forward to implement with the recent
RestInterface!T refactoring in place.

Is there awareness about these issues? Do I need to post bugs?

I would gladly help with implementing some features.