Understanding REST: REST as a high volume transport?

Question

I'm designing a system that will need to move multi-GB backup images over TCP, and I'm looking at REST as an alternative to ONC RPC.

For example, I might have

POST http://site/backups/image1

where image1 is an 50GB file whose data is contained in the HTTP body.

My question: is this within the scope of what REST is meant for? Is it inappropriate to move massive files over HTTP? My preliminary testing shows that the performance isn't too bad, and I like the clean, debuggable protocol, as opposed to a custom ONC RPC server. But is this overloading the role of a webserver?

Thanks, -Steve

Answer 1

HTTP has about the same overheads as FTP.

An HTTP server if often asked to do more work than an FTP server. But otherwise, using HTTP to send a large file is about the same as using FTP.

The only consideration is making sure your web server and web application framework are configured to do this kind of thing without needlessly expanding the entire 50Gb file inside Apache.

Answer 2

Steve,

HTTP has a look-before-you-leap 'feature' that allows the client to ask the server whether it will accept the data submission before it actually sends out the data. I'd look into using this to avoid transferring GBs of data only to find out that the server is currently not willing to handle them. Look at the HTTP Expect header and 100 Continue status codes.

Also, you can use FTP within a RESTful approach, IOW, think along the lines of

<backup-store href="ftp://example.org/site/backup/images/"/>

and make your clients understand the ftp URI scheme.

Finally, the T in HTTP means transfer and not transport - an important distinction to make because the former is an application semantic (HTTP is an application protocol) and the latter is a not.

HTH,

Jan

Answer 3

REST has nothing to do with how large your data is or which method you use to transport it.