Web service for retrieving chunks of data

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.