If you think it's a viable concern, then just don't use a 301. Keep the old
URL and make the new one, and have them both return the right content.
On Thu, May 5, 2011 at 10:52 PM, Jason Erickson <jason_at_jasonerickson.com>wrote:
> Yeah, it's not so much the option as the default behavior I'm worried
> about. If I can't be reasonably certain that clients (that I don't write)
> will react predictably to a 301, then it's not really backwards compatible
> anymore.
>
> On May 5, 2011, at 7:07 PM, Ryan Stewart wrote:
>
> I don't have much experience in those other areas you mention, but I'd be
> shocked if any serious HTTP client didn't have an option for doing that.
>
> On Thu, May 5, 2011 at 8:44 PM, Jason Erickson <jason_at_jasonerickson.com>wrote:
>
>> I guess it shows that I'm relatively new to REST (at least new to taking
>> it seriously beyond just XML and JSON over HTTP) that Conal's solution
>> didn't immediately occur to me.
>>
>> Do most HTTP client libraries handle 301's transparently, or would the
>> client have to be written explicitly to expect the possibility of a 301 and
>> handle it gracefully? e.g. I know that Apache HttpClient will swallow a 301
>> and redirect, then give the final status of the redirected URL (200, 404,
>> etc.) Will .NET do the same? Applications written for iPhone and iPad?
>>
>>
>>
>