Is RESTful API appropriate for the following scenario?

  • A time-limited token is obtained, which will last for one minute only
  • Image is uploaded to a server
  • Server performs some CPU-heavy image processing upon request, within the time limit
  • The result is available for download, within the time limit
  • When the token expires:
    • The image, computation, result are all discarded / terminated, and any open connection will be closed.
  • All other necessary aspects of web services, such as authentication / service authorization, quota, encryption etc., might still be necessary.

Since the "resource" is only allowed to exist for less than one minute, does it still make sense to make "resource" the first-class citizen in this API?


I have found this link that talks about a REST API for job queueing in RabbitMQ. However it is an "idea page", so I'm not sure whether this is relevant or not.

3 Answers 3


REST as a transport protocol is suitable, as an architectual paterrn it might not be enough. Lets assume that you would want to distribute the computation accross multiple servers. This would require round robin load balancer to even out the load, and sticky sessions to ruote the result request to the same server that processed the image. You should take a look at master worker job distribution frameworks such as cellery that are based on queues, and at low latency computation frameworks such as storm.

  • 1
    REST isn't a transport protocol. REST is implemented over a transport protocol.
    – kdbanman
    Commented Jun 24, 2015 at 21:11

It seems like your reading too much into this.

RESTful API is just a more lightweight stripped down version of SOAP, most commonly it will use JSON (not required) as its generally used for smartphones because its much more lightweight for an environment where a user may have a bad connection or be charged for using it.

SOAP web services have built in benefits for security, encryption etc. if these are going to be required it sounds like you should use SOAP instead of trying to implement your own on top of REST


I suppose there's no harm to using restful if you're only using get with the id of the download in order to start download of a file. Just a couple important points to observe:

  1. I would just be careful to make every other standard restful accessor disabled if you're not going to use them (what sense does update and delete have at that point?). You could still use post to upload the initial file, since that still fits the pattern.
  2. Change the root to distinguish from other more normal restful accesses, even if the file being uploaded involves updating a record which is normally accessed through restful (i.e., if you have /api/files as a root for crud operations on records regarding files, have an /api/files/upload root for the actual file upload).

Restful is meant primarily to simplify server/client interface, so if you run into some sort of trouble, don't wrack your brain trying to make it work. Simply abandon restful for this type of transaction.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.