views:

229

answers:

3

Hi,

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

A: 

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.
John Feminella
A: 

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.

Daff
Thanks all of you for your answers. @Daff idea was the initial one I had. Could you further explain the 'complete' tag?The issue is I might have not described completely the idea of the service. The thing is I need to send back to the server the result from loading the data into the device. Then the server will check if an error has occured and return the next chunk or an error indicating the client should stop sending data to the device and close connection to device.Hope you can still help me out. I like the idea under rest but still have some doubts on what can be implemented using it.
jlanza
Hm I'm not sure if I exactly get what you want to do. But Kevin may be right that this is what the HTTP range headers are for and if the server finds an error it will return one of the HTTP error codes. Therefore you should check if the client can package it's information about a successful processing into the request header or (if that doesn't work) as a URI parameter of the next chunk, too.
Daff
The thing is the device only accept chunks and the server needs to authenticate that a chunk has been correctly uploaded in the device. In this sense, upon sending the data to the device, the response from the device has to be sent to the server who will check if the data is correct or not (there are some cryptographic issues in the middle).
jlanza
So the device would send more information back to the server in a request than just a "Received and processed chunk #123" or "Error processing chunk #123" (which I guess would work with the If-Range header in the request, see http://en.wikipedia.org/wiki/HTTP_header )?
Daff
That's it. The device response would be a value that the server needs to decript in order to verify the data has been properly loaded. If it has been properly loaded it will send the next chunk and if not it will terminate. Thanks very much for your help. I think we are converging and your experience will help a lot.Imagine the device is a attached to a serial port and the server is sending the data that the client has to sent to the serial port. Then the answer will be transmitted back to the server, checked and in case correct send the next command. This is more or less the idea.
jlanza
Hm then you should try if a different approach (if you still want to do it RESTfully) will be better. Imagine you have a status resource which your client will PUT onto the server whenever it did something. It will be processed and saved by the server and if the client then requests that status it can link to the next file chunk (e.g. /status/id/chunk/ will return the next chunk or one of the 4xx or 5xx HTTP errors)
Daff
I still want it to be restful. During the weekend I thought more or less on a similar approach, considering that a GET returns the command and a PUT with the response returns a field with the status and next link. So it is very similar to yours. Thanks a lot for your help.However, I sitll have one more question. Is the app I'm planning the typical one to be RESTful? I have usually seen RESTful applications that access to database (easy resources) but not like mine.TA
jlanza
Well REST is about breaking everything down into resources whereas many developers are more used to think in the terms of Remote Procedure Calls. Database entries are just the most obvious thing to be considered a resource, but I think you can break down many problems into resources. It is on yourself to decide if REST is the more adequate (imho: simpler) sollution to a RPC. If your RESTful breakdwon seems to complicate you should try an RPC protocol like SOAP. Btw. don't forget to mark your question solved if any of the answers helped you at least a little.
Daff
Thanks a lot. I know I can break my service into resources... it is like thinking with objects in normal programing. Let's give REST a try!!!
jlanza
+3  A: 

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

Kevin