1

I'm building a java REST API using JAX-RS and to complete a GET request for a zip file I need a rather sizeable chunk of JSON to complete it. I'm not terribly experienced with REST but I do know that GET requests shouldn't have a request body and a POST shouldn't be returning a resource. So I guess my question is, how do I complete a request that contains JSON (currently in the message body) and expects a zip file in the response while keeping the application RESTful? It may be worth noting that the JSON could also contain a password

  • Based on these requirements, it might not be prudent to keep your application completely RESTful. The GET request would have to send the data in the URL as URL params, which has a length limit, I believe. I recommend just using POST even if you feel it's breaking the RESTful nature of it. Ultimately it will probably make more sense. – shieldstroy Oct 28 '15 at 23:21

2 Answers2

1

I have used POST for similar scenarios. This is a common scenarios for SEARCH operations where there is a need to send json data in request. Though using POST for getting an object is not as per REST standards, I found that to be the most suitable given the options available.

You can send body in GET requests, but that is not supported by all frameworks/tools/servers. This link discusses that in detail.

If you use POST for the operation, you can use https to send confidential information in the body.

Community
  • 1
  • 1
pawinder gupta
  • 1,161
  • 12
  • 30
  • The accepted answer is actually incorrect, because the question is about how to keep the API RESTful for that problem, not about an workaround... – npclaudiu Nov 01 '15 at 22:24
0

You can think that your REST API exposes a virtual file system and the zip file you mentioned is just one resource in that VFS and have files in a certain directory to represent queries of that file system. Then you can create a new query object by sending a POST request to the queries directory, specifying all query parameters you need, such as chunk size and the path of the zip file in the VFS.

The virtual file system I am referring to is actually a directory containing other directories and files that can represent real files on the disk or metadata records in a database.

For example, say you start with the following directory layout in the VFS:

/myvfs
    /files
        /archive.zip
    /queries

To download the archive.zip file you can send a simple GET request:

// Request:
GET /myvfs/files/archive.zip

But this will stream the entire file at once. In order to break it in parts, you can create a query in which you want to download chunks of 1MB:

// Request:
POST /myvfs/queries/archive.zip

{
    chunk_size: 1048576
}

// Response:
{
    query_id: 42,
    chunks: 139
}

The new query lives at the address /myvfs/queries/archive.zip/42 and can be deleted by sending a DELETE request to that URL.

Now, you can download the zip file in parts. Note that the creation of the query does not actually create smaller files for each part, it only provides information about the offsets and the size of the chunks, information that can be persisted anywhere, from RAM to databases or plain text files.

To download the first 1MB chunk of the zip file, you can send a GET request:

GET /myvfs/queries/archive.zip/42/0

As a final note, you should also be aware that the query resource can be modeled to accommodate other scenarios, such as dynamic ranges of a certain file.

P.S. I am aware that the answer is not as clear as it should and I apologize for that. I will try to come back and refine it, as time permits.

npclaudiu
  • 2,259
  • 1
  • 14
  • 17