REST Web Service redirect

Question

I have a web service designed in the REST architecture.

I want to have one end point for allowing the user to upload a picture.

I'm using AWS and I want to create the whole service in a way that one server is getting the requests and then (if needed) it will redirect to the relevant server for processing the request.

For example: Sending an HTTP Post request with a parameter containing a picture to: rest.myservice.com/picture/upload will redirect the request to right server (or even directly to the right S3 path).

Just for clarification, the redirection is not the problem, but I want it to redirect the route before it receive the whole picture (for performance and time saving).

Is that possible?

Answer 1

It might arguably be better if you reconsider this requirement and design your system with a front-end layer that can take care of delivering the request to the correct server.

This is easy to do with a reverse proxy server. An example of this would be HAProxy, which can route requests to back-end servers based on URL pattern matching, cookies, and other rules you define, and is extremely low in resource usage (even a t2.micro instance can handle hundreds of simultaneous connections).

I say all this because redirecting requests other than GET requests can get you into areas of inconsistent/bad browser/user-agent behavior territory, where the redirection can fail on one browser (or version) while working correctly on another.

Similarly, there's inconsistent behavior to be found in the mechanism that allows a request in flight to be interrupted for a redirect (or an error response) before the payload is sent:

https://www.rfc-editor.org/rfc/rfc7231#section-5.1.1

If the user agent includes an Expect: 100-continue header with the request, then the user agent should wait for your service to send the 100 Continue response before it actually sends the payload, which allows you to alternately send either the redirection response or to tell it to proceed with the payload... but this depends on the user agent setting this up in the request and properly handling the response. It's not unheard of for a user agent to send the Expect: header and then send the payload without actually waiting, which should still "work" bit doesn't do what you want, consistently.

However, if that's "close enough," then it could be worth trying... an example of a real-world implementation of this is in S3 itself, which supports the Expect: header... at least on PUT object requests. Browser-based POST upload docs don't mention this, but they do have a caveat about redirection of POST, which is only likely to occur shortly after bucket creation, before the "bucket.s3.amazonaws.com" hostname is updated in DNS (by S3 itself: to send requests to the correct regional endpoints.

If your bucket was created using <CreateBucketConfiguration>, your end users might require a redirect. If this occurs, some browsers might handle the redirect incorrectly. This is relatively rare but is most likely to occur right after a bucket is created.

http://docs.aws.amazon.com/AmazonS3/latest/dev/HTTPPOSTForms.html#HTTPPOSTConstructingPolicyRedirection

I mention this last part, only because it supports my assertion that browsers and other user agents cannot, unfortunately, be trusted to handle redirects consistently or gracefully.