Is it a violation of REST conventions to have the response to a request be a redirect to another URL?

[msskiran]

I am designing a system where a user would click on a URL which is a
RESTful URL.Now I also wanted the user to be redirected to a diff page
or a URL based on the outcome of the request. You can say that I have
multiple callbacks based on multiple outcomes. Is that RESTful
procedure? Or is there a standard way of doing this? Thanks.

- Shashi

[Carlos Eberhardt]

Is the response cacheable? Not sure if that's a decent rule of thumb or not, but if I can't cache the response it makes me think a GET might not be the most appropriate method.

-Carlos 

[mca]

Shashi:

First, Fielding's dissertation has nothing to say about redirecting HTTP requests so you're not committing any "violation" of his style.

Second, HTTP supports lots of possible redirection options (301, 302, 303) so you're not violating any protocol, either.

Finally, you should keep in mind the way redirection works is that you tell the *client* too "go here to get your response"; it is essentially two requests now:

1) client sends POST request to some URI; server returns a 3xx response telling the client to

2) send a GET request to some URI

this can, essentially double your traffic on the server. If you are paying per request, your costs go up directly<g>. Even if you are not paying per request, the added traffic might adversely affect your ability to scale your app up.

there is also a very slight chance that some clients will not follow the redirection requests, but i think that's not a big consideration.

FWIW, if this were my project, I'd work on changing the request/response pattern to reduce the number of redirects generated by the server.

mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me

[Matthew Bishop]

We thought about this idea in our API but rejected it because it
violates the Principle of Least Surprise.

What we did instead is created a representation that has a link to the
location they should go to next. This may be "chattier" but that's
preferable to the ambiguity of what might happen as a result of the
first call.

Trying to eliminate chattiness is an optimization that should not
obfuscate the understanding of your API.

Matt

On May 16, 5:55 am, mca <m...@amundsen.com> wrote:
> Shashi:
>
> First, Fielding's dissertation has nothing to say about redirecting HTTP
> requests so you're not committing any "violation" of his style.
> Second, HTTP supports lots of possible redirection options (301, 302, 303)
> so you're not violating any protocol, either.
>
> Finally, you should keep in mind the way redirection works is that you tell
> the *client* too "go here to get your response"; it is essentially two
> requests now:
>
> 1) client sends POST request to some URI; server returns a 3xx response
> telling the client to
> 2) send a GET request to some URI
>
> this can, essentially double your traffic on the server. If you are paying
> per request, your costs go up directly<g>. Even if you are not paying per
> request, the added traffic might adversely affect your ability to scale
> your app up.
>
> there is also a very slight chance that some clients will not follow the
> redirection requests, but i think that's not a big consideration.
>
> FWIW, if this were my project, I'd work on changing the request/response
> pattern to reduce the number of redirects generated by the server.
>

> mcahttp://amundsen.com/blog/http://twitter.com@mamundhttp://mamund.com/foaf.rdf#me