Response and Request Entity Bodies and Java types

From WebLichtWiki

(Difference between revisions)
Jump to: navigation, search
(Created page with "Jersey uses Entity Providers to map between HTTP Response and Request Entity Bodies and their associated Java types. Among the standard types that are supported automatically...")
 
 

Latest revision as of 15:26, 13 December 2012

Jersey uses Entity Providers to map between HTTP Response and Request Entity Bodies and their associated Java types. Among the standard types that are supported automatically for Request Entities are InputStream, we use InputStream for accessing the TCF input sent by the client in all the tutorials at Creating a WebLicht Web Service Another supported type, bytes[] type, we use for returning the output to the client in all the tutorials. Additionally, in Tokenizer and Sentence Boundary Detector Service we provide an implementation of the @POST annotated method that returns StreamingOutput implementation. StreamingOutput type is supported only for Response Entities.


let's consider Tokenizer and Sentence Boundary Detector Service example. It demonstrates two ways of returning the TCF output in HTTP response: as a StreamingOutput (see TokSentencesResource method annotated with @Path("stream")) and as an array of bytes (see TokSentencesResource method annotated with @Path("bytes")). Both ways have their advantages and disadvantages. In case of returning bytes array the implementation is simpler, but the whole array containing output TCF is constructed in memory, so in case the TCF output is big, the server might run out of memory. In case of returning StreamingOutput, the implementation is slightly more complicated, but it makes possible to handle TCF output of bigger size.


The provided in Tokenizer and Sentence Boundary Detector Service implementation with StreamingOutput writes output to a temporary file before writing to the streaming output. This is necessary step in order to catch errors that can occur during TCF reading/processing/writing. Otherwise, if the error occurs when the server is in the process of streaming the data to the client, the server response will be confusing: HTTP status is sent as OK (because it is sent when the streaming starts and before the error occurs), while output itself would contain half-written not finished TCF data. This will break WebLicht chain processing, - in case of erros WebLicht needs to be notified with corresponding error HTTP status code and status massage. On the other hand, if writing to the temporary file was successful and no errors occur during the processing, then the streaming output can be used to return data from the temporary file to the client.