On Sun, 18 Aug 2013 06:37:38 GMT, Sönke Ludwig wrote:

On Sat, 17 Aug 2013 19:52:03 GMT, Craig Dillabaugh wrote:

On Thu, 15 Aug 2013 20:27:11 GMT, Craig Dillabaugh wrote:

I am trying to implement a simple REST API that returns some binary data to a user (it could be BSON format or just the RAW binary data).

Say I define the following interface: 

@getRootPathFromName
interface MyAPI
{
    @path("getdata") @method(HTTPMethod.GET)
    ubyte[] getData();
}

class MyImpl : MyAPI
{
    override ubyte[] getData() {
       ubyte[] the_data;
       the_data ~= 1;
       the_data ~= 2;
       the_data ~= 3;
       return the_data;
    }
}

Running code like this returns the text '[1,2,3]' in JSON format. If I want to send the binary data (or perhaps a file - say .png or .jpg) how could I handle this.

So I guess this was a dumb question :o)

Not at all ;) Sorry, I'm currently struggling a bit keeping up with the forums and e-mail messages.

So the short answer is: This is not possible using the REST interface generator. A manual route would have to be registered in the URLRouter and a custom HTTP request needs to be constructed on the client side. Those would then work alongside MyAPI.

However, I think this is common enough to warrant direct support in the REST generator. How about recognizing a method signature of the form void method(..., OutputStream, ...). The REST server would then directly write the response to that stream and the client would pass the contents of the bodyReader to the caller. The "Content-Type" could for example be defined using a @uda.

Any other ideas? I'd prefer a stream based solution to be on the safe side regarding big responses and to be able to avoid allocations if necessary, but maybe a @uda could also be used to support ubyte[] return types for achieving the same result.

I thought I had already replied to this already, but since I see nothing on the form I will try again.

I am quite new to web-app develpment and UDAs so I am not sure how helpful my comments on the proposal will be, but I like the general idea. The solution you propose is close to what I 'expected' to happen so I guess that is a good sign. I doubt there are many web-applications where a raw binary array is the expected by the client, so I think the OutputStream based solution makes sense.

Just curious, when you say the 'client' would pass the contents of the 'bodyReader' to the caller, what does that mean? (in my thinking client == caller).