Hello,
I am attempting to construct a web service and a client test of that
service that accepts a variant number of string parameters as well as
a variant number of files in a REST request. I see a variety of
examples around the internet that all advocate slightly different
approaches, and all deal with a portion of the problem, but everytime
I go down one path or another some error blocks me. So what is the
appropriate way to approach this both from jersey client point of view
and server point of view?
On the server side I saw some people using annotations on their
parameters to get an input stream for file uploads, but I have variant
numbers of files (0-n). So I ended up using @Context to get the
request and tried applying apache commons file upload to it, but kept
getting exceptions because I presume I wasn't constructing it
correctly on the client.
On the client, I tried using com.sun.jersey.api.representation.Form
and just using the add() method to add string params and byte arrays
as parameters (which I thought was wrong, but i figured the add
interface with a Object would maybe create the attachment
automagically), and got errors saying "the request was rejected
because no multipart boundary was found".
I tried using FormDataMultiPart in a similar way with the field()
method and suddenly I get 400 errors (bad Request) even though my
server code does not specify a specific MIME type to consume. Just
@POST and @Path annotations. Control never arrives.
I tried a variety of other tweaks along these lines and each returns
some error or another. The examples I see always seem simplistic,
sending only a file, or only form parameters, and on the server
receiving only one file. Can someone tip me off to what I should be
using, or a resource that really explains what to do? There is alot
of help on this stuff, but it all lightly touches issues and doesn't
seem to actually drill down to the details. Very frustrated.
I can post sample code, but I've iterated over so many different
things, I'm not sure which to post at this point.
Brian Mulholland