I went to a open lecture about Jersey REST web service and made some notes. Here is what the lecturer said in the lecture, I am quite confuse about it.
i.you will need POST some content to /files/. For example, you
have a file locally called data.json.Posting the content of that file
to your REST service will store the content on the server with a name
it chooses automatically, say 3.json, in a folder chosen by you.
ii.The key thing here is the REST service will need to manage the
files it creates by choosing a name that hasn't been used and return
that name to sender, so the sender can re-download the content it sent
using the name it gets.( The sender do not know which name the content
will be given until it receives the response from the REST service).
For step i, is that means upload a file to the service and save to a new location? What is mean by the service will give it a name automatically?
For step ii, is that means if I send three files into the service, when I call GET /files/1, GET /files/2 and GET /files/3 will return the content of 1.json, 2.json, 3.json respectively? Besides the lecturer said we can use curl command line to post a file to the service.
The lecturer did not provide any example, which made me not understant it clearly.
Is it possible to help me to write a demo about that or provide some examples to me?
you have a file locally called data.json
Alright, simple enough
Posting the content of that file to your REST service will store the content on the server
Sure, saving files. It reads that POST data, and stores it to disk.
a name it chooses automatically
This is a minor detail... It could be stored as the same name, but then you'd have conflicting filenames.
in a folder chosen by you
That point isn't really clear... but, moving on.
the REST service will need to manage the files it creates by choosing a name that hasn't been used
Exactly the earlier point.
and return that [...] to sender
Think about a typical website... You request http://stackoverflow.com. It returns back HTML. Your REST service is just returning a string / file.
return that name to sender, so the sender can re-download the content it sent using the name it gets.( The sender do not know which name the content will be given until it receives the response from the REST service).
The client needs to know the name of the file that was added. Otherwise, you don't know how to request the file; the server had generated its own name for the file you sent to it originally.
if I send three files into the service, when I call GET /files/1, GET /files/2 and GET /files/3 will return the content of 1.json, 2.json, 3.json respectively?
Not quite - The server generated the names of the files. So, a better example would be
POST -d file.json /files
Outputs the text
20160801-21-38.json
And in order to request that file back, you now need to use that value
GET /files/20160801-21-38.json
Related
I want to implement image uploading in my web application which has backend in java and frontend in javasciprt/jquery/html/css and uploading on amazon s3.
I can see Fine-uploader generating a highly randomized key for a file and get that key signed by passing it to signature end point (along with some more headers).
My question is, what if somebody send some other key to signature end point and upload file with that key; in a way, he can try overwriting my already placed file.
How can I implement following logic in fine-uploader-
Fine uploader hit end point for signature
I generate some randomized key on server (sign that key and other headers) and pass signature, policy and key back to the client
Now on same key I do upload and bookeeping
please excuse me for typos and my bad english
While your initial question is a bit unclear, in your comments you have expressed a desire to ensure a user does not tamper with the request/policy, perhaps in an attempt to upload a file with a duplicate name. If you'd like to prevent this, simply query your database (or your bucket using the S3 API) server-side as part of handling the signature POST from Fine Uploader. If a file by that name already exists, then return a 500 response with a JSON message body like this: {"invalid": true}. This signals to Fine Uploader that the policy or request headers are invalid and the upload will be canceled.
My main question is how can I pass JSON as well as File to post request to REST API? What needs in Spring framework to work as client and wait for response by passing post with JSON and File?
Options:
Do I need to use FileRepresentation with ClientResource? But how can I pass file as well as JSON?
By using RestTemplate for passing both JSON as well as File? How it can be used for posting JSON as well as File?
Any other option is available?
Sounds like an awful resource you're trying to expose. My suggestion is to separate them into 2 different requests. Maybe the JSON has the URI for the file to then be requested…
From a REST(ish) perspective, it sounds like the resource you are passing is a multipart/mixed content-type. One subtype will be application/json, and one will be whatever type the file is. Either or both could be base64 encoded.
You may need to write specific providers to serialize/deserialize this data. Depending on the particular REST framework, this article may help.
An alternative is to create a single class that encapsulates both the json and the file data. Then, write a provider specific to that class. You could optionally create a new content-type for it, such as "application/x-combo-file-json".
You basically have three choices:
Base64 encode the file, at the expense of increasing the data size
by around 33%.
Send the file first in a multipart/form-data POST,
and return an ID to the client. The client then sends the metadata
with the ID, and the server re-associates the file and the metadata.
Send the metadata first, and return an ID to the client. The client
then sends the file with the ID, and the server re-associates the
file and the metadata.
Basically I need to provide REST service that would receive a String param, use that param to fetch a file from another system and then return the fetched file back as the response.
The effect should be the same as when a user clicks on a pdf or any other binary file link and the browser prompts him to save/download that file.
A couple of points:
is it possible to stream the file (to send bytes as I receive them from source system). In other words, how to handle very large files?
also related to streaming, when using regular HttpServletResponse, do I have to wait until a large file is completely read to return response.build()?
How do I go around doing this using Apache Wink?
PS Sorry, this may be trivial for Wink gurus, but I'm just starting to wrap my head around developer guide.
You can just return the java.io.File from your method. You can wrap it with Response if you like. Wink will handle the streaming. The streaming doesn't start when you call to response.build(), but rather when your method finishes.
If you want a correct download dialog, you should return the proper Content-Disposition header. See How to set response header in JAX-RS so that user sees download popup for Excel?
In one of my #RequestMapping POST methods I need to return HttpServletResponse (which is an xml file) and I want to refresh the view. Normally I would just return path but in this case it gets appended to the xml file which is being downloaded by user.
Is there any way to close and send response first and then generate(refresh) view?
I would say no, it's not. Not a 100 percent sure though. You could try to send the file and also set the redirect header in your response. I didn't try it just now but I guess you will just be redirected. Really depends on the browser though. A browser could decide to still download the file.
Once you sent the response a new request needs to be generated by the client, so there is no way to close it server-side and just create a new one.
I would suggest a solution using Javascript. Either AJAX or just setting the current location twice (first the download, then the new view). I'm not sure, I guess via location.href
Let me know if you need an actual code example, as it would take me some time to manufacture something.
I'm planning to develop a webservice, and I like to try the RESTful architecture. The issue is that I don't know if the service is adequate for it, or it is better to use SOAP.
The service is about downloading some data from the server to a device on the local computer. The data will be split into chunks. The service will be run with an ad-hoc client at the local machine that will manage the device the file is gonna be stored in.
I was thinking on having something like:
/files/{id} --> will inform about the details of the file
/files--> list all the files
The problem is for the action. In rest only GET, POST and (PUT DELETE) are defined. But I want to have something like download. My idea, although not fully restful is to create:
/files/{id}/download
This will return something like
{ "chunk" : "base64 string with chunk data"
"next" : "http://XXX/file/id/download?chunk=1
}
When next is empty the whole set of chunks would be downloaded.
What do you think? Is it ok to do it this way or would it be better the traditional way using SOAP and defining functions like getFiles(), getFileChunk(chunkNo, file)?
Any comment is really appreciated.
See you
If using REST, you don't need to define your own "chunking" protocol as the HTTP headers Content-Length, Content-Range and Transfer-Encoding are all used for sending chunked data.
See the RFC for HTTP header fields
As John already mentioned you might want to separate between your file resources and the file resource metadata (any information about your file). Additionally a more RESTful way to access your chunks could look like this:
http://url/files/{id}/chunks
{
"complete" : false,
"chunks": [
"http://url/files/<fileid>/chunks/1",
"http://url/files/<fileid>/chunks/2",
"http://url/files/<fileid>/chunks/3",
]
}
Basically, here, you return a list of RESTFUL URIs to all your file chunks and the information if all chunks of the file are already complete. I don't see that SOAP might have any advantage there since you would define the same methods (getFile and getChunks) that are already covered by the REST verb GET.
It sounds like you really have two different resources: file-metadatas and files. What about something like:
/file/{id} // GET: Retrieve this file's data.
/file-metadata/{id} // GET: Metadata about a particular file. Contains link to file:
// {
// ...
// data: "http://.../file/156", // Where to find file's data.
// }
/file-metadata // GET: List metadata for all files.