Uploading multiparts is also supported, see...
Thanks for the response!
I guess where I was coming from was this: On the server (receiving a
file) side of things, I have code that works (nicely, even -- it
streams the data [transparently to me], and doesn't out-of-memory on
large files)... It's copy/pasted below, for reference. What I was
wondering is whether this approach is *reasonable*. :-) And if not,
what do people recommend instead (as a "standard", if you will).
As it is, this code lets a client send me a file with arbitrary
content, and I can receive it and store it on my end (in a domain-
appropriate way). And as it happens, I've verified that I can write a
perl client easily enough, that also works nicely with this approach.
Is there a reason not to do it this way, though? Is a multipart,
encoded-somehow-or-another approach better for reasons that aren't
obvious to me, as a newbie to this?
On the sending side (server to client), is there a reason not to send
in the analogous fashion -- as application/octet-stream? Seems like
the only real down side is that, because the MIME type is generic,
doing something like pointing your browser at the URI for a resource
that happens to be a JPG (for example) won't yield the intuitive
result; rather than just being shown the image, you'll be asked where
you want to save the download.
Thanks for your insight and guidance!
Server-side:
@POST
@Path("/{name}")
@Consumes("application/octet-stream")
public void addFile (@PathParam("id") String id,
@PathParam("name") String name,
InputStream text)
throws Exception
{
FileOutputStream fos =
new FileOutputStream(new File("/tmp/attachment"));
copyStream(text, fos, 16384);
fos.close();
}
}
Client-side:
WebClient client = WebClient.create("http://127.0.0.1:8080/CXFPlay/
rest");
InputStream inp = new FileInputStream(args[2]);
Response res =
client.path("defect/" + args[0] + "/file/" + args[1])
.type("application/octet-stream").post(inp);
