Closed mgrojo closed 1 year ago
There are two things to consider: the client side and server side.
For the client side, the client response is available as a string through Client.Response.Get_Body
.
The Swagger.Clients.Call
procedure must be improved to look at the Content-Type
and handle the response accordingly. This is not done due to lack of time on my side.
For the server side, the response stream is a Servlet.Rest.Output_Stream
which is an alias for Util.Serialize.IO.Output_Stream
.
This gives a direct access to the output stream and you can write text and even binary content.
I'm using it for the AWA servlets that return a jpeg, png or other document types.
That response stream is easily accessed from the Reply
parameter passed to the REST operation.
I don't have much time to investigate because I'm busy preparing two presentation for the FOSDEM 2022.
Thanks. For the moment, I'm interested in the server side.
I've found where is the JSON stream declared, I think it's here: servlet-core-rest.adb#L77. I suppose this Dispatch
could consult the Accept header of the Request
and set either the JSON or the (new?) text/plain implementation of Util.Serialize.IO.Output_Stream
. Would that approach work?
I'm looking forward to those FOSDEM presentations.
Yes, it could check the Accept header there.
Now, you can also override the Set_Content_Type
that is done and write directly on the Response stream.
The following
Output : constant Streams.Print_Stream := Response.Get_Output_Stream;
should allow you to write text or binary as you wish in whatever format.
I think there is missing an API Descriptors that allows to write raw streams. Such API descriptor would only get the following two parameters:
Request : in out Requests.Request'Class;
Response : in out Responses.Response'Class
Basically, I wish I could do something similar in Java Jersey where you can register different API handlers for different response types. The framework should then handle the choice and execute one handler or the other.
As far as JSON, XML, Form are concerned, the Streams.JSON.Print_Stream
makes sens.
For text or binary, they are not necessary and only the request and response parameters are useful.
Fixed in 0.7.0
After a test with an openapi with text/plain as response, I think it only supports json, because the response header says it's json and the output is quoted and end of lines replaced by
\n
.In case it is not supported, how could it be implemented? I was looking at the code, and it seems that the stream used is
Util.Serialize.IO.JSON
. I suppose I'd have to implement a new kind of stream for simple text output, but I don't see where the object with the particular type of stream is declared.