rest api design and workflow to upload images.

Question

I want to design an api that allows clients to upload images, then the application creates different variants of the images, like resizing or changing the image format, finally the application stores the image information for each of the variants in a database. The problem occurs when I try to determine the proper strategy to implement this task, here are some different strategies i can think of.

Strategy 1:

Send a post request to /api/pictures/, create all the image variants and return 201 created if all image files were created correctly and the image information was saved to the database, otherwise it returns a 500 error.

pros: easy to implement

cons: the client has to wait a very long time until all variants of the images are created.

Strategy 2:

Send a post request to /api/pictures/, create just the necessary information for the image variants and store it in the database, then returns a 202 accepted, and start creating the actual image variant files, the 202 response includes a location header with a new url, something like /api/pictures/:pictureId/status to 'monitor' the state of the image variants creation process. The client could use this url to check whether the process was completed or not, if the process was completed return a 201 created, if the process is pending return a 200 ok, if there is an error during the process, it ends and returns a 410 gone

pros: the client gets a very fast response, and it doesn't have to wait until all image variants are created.

cons: hard to implement server side logic, the client has to keep checking the returned location url in order to know when the process has finished. Another problem is that, for example when the image variants are created correctly but one fails, the entire process returns a 410 gone, the client can keep sending requests to the status url because the application will try to create the failed image again, returning a 201 when its end correctly.

Strategy 3:

This is very similar to strategy 2 but instead of return a location for the whole 'process', it returns an array of locations with status urls for each image variant, this way the client can check the status for each individual image variant instead of the status of the whole process.

pros: same as strategy 2, if one image variant fails during creation, the other variants are not affected. For example, if one of the variants fails during creation it returns a 410 gone while the images that were created properly returns a 201 created.

cons: the client is hard to implement because it has to keep track of an array of locations instead of just one location, the number of requests increases proportionally to the number of variants.

My question is what is the best way to accomplish this task?

Answer 1

Your real problem is how to deal with asynchronous requests in HTTP. My approach to that problem is usually to adopt option 2, returning 202 Accepted and allowing the client to check current status with GET on the Location URI if he wants to.

Optionally, the client can provide a callback URI on a request header, which I will use to notify completion.