Hi ks,
KSChan wrote:
> I get the blob and content type back from DB ... but, how can I
> "dynamically" change the produce mime so that the user can "download"
> with xxx.jpg or yyy.png or zzz.pdf instead of xxx or yyy or zzz
> without extension ... ??
It is not possible to dynamically change the ProduceMime annotation.
Annotations are statically defined and fixed. You have done the right
thing and used a wild-card media type and returning Response, as it the
application that is dynamically specifying the exact media that is produced.
Do you want to support both 'xxx' and 'xxx.pdf', namely canonical and
distinct URIs respectively, or just the latter?
If just the latter than you could mandate that the URI template requires
a suffix, @UriTemplate( "/obtainCopy/uuid={uuid}.{suffix}" ), or you
just could check for the suffix in the uuid param if using @UriTemplate(
"/obtainCopy/uuid={uuid}" ).
Perhaps in this scenario it may make more sense when getting the content
to refer to the name that was used to upload the content, since it is
the client that is defining the name in the form (but i guess it depends
if you want to avoid conflicts or not). For example:
@ProduceMime( "application/*" )
@UriTemplate( "/content/{name}" )
@HttpMethod( "GET" )
public Response obtainCopy( @UriParam( "content" ) String name ) {
...
}
A tip, it is always good to try and avoid verbs in the URI path and
instead use nouns (that better reflect that one is exposing state), not
particularly because the client should care although the human might,
but it helps the thought processes when designing your RESTful service
to avoid getting into the RPC-trap and thinking of additional methods
beyond those provided by HTTP.
Another tip, you can use InputStream directly:
return Response.Builder
.ok( file.getBinaryStream() )
.type( contentType )
.build();
so you don't need to create an in-memory buffer of the content, which is
more efficient when returning large content.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109