Re: Change language. POST or GET

On Tue, Dec 23, 2008 at 07:42:22PM +0100, Julian Reschke wrote:
> Carlos Tejo Alonso wrote:
>>  >> Maybe I have express myself wrong. I will try again with an example:
>>  >> I am abroad, using a shared pc with arabic language as default. I send a
>>  >> request to the URL By content negociation, a
>>  >> server will response with a page written in arabic. In that moment, I
>>  >> want to change the language of the content, and the return page should
>>  >> be again
>>  >> What would be the correct approach ?
>>  >> - a link that invokes a HTTP GET method
>>  >> - a button that invokes a HTTP POST method

My preference would be to use both language-neutral URLs, that use
content negotiation to determine the language, and language-specific
URLs, that return a page in the language that corresponds to the URL.

For example,

HTTP redirects from former to latter can be used.
Other properties (e.g. character set, locale) can be treated
in the same way.

>>  > It seems to be that you're changing the state of the server, thus  > 
>> GET would be incorrect.
>> I disagree.  The Accept-Language: header is responded to in the reply  
>> to the GET request containing it and does not alter state on the server.
>> The server is ready on the next hit from anyone to provide the same range
>> of languages as on this hit. With the same server defaults, not
>> defaulting to the last request satisfied.

State should be encoded into URLs as much as possible.

> You didn't tell us before that sessions are in use.
> But anyway, you're changing state, so GET is the wrong thing to do here.

I don't think so.  You're changing session state only, and as long as
the session state is fully encoded into the URL and/or request headers,
the request itself is stateless (its response is fully determined by the
request) so GET is the appropriate choice.

>> If you click on the flag of your national language on a site to get that
>> language version, that is changing the state of your session, yes.

But that doesn't necessarily make the requests themselves stateful.
Making them stateful without good reason is bad design practice,
according to many.

>> That's the problem: the way to interprete it. I am looking for a  
>> normative answer from W3C, but I haven't found yet anything in the  
>> documentation about it.
> You can't get a "normative" answer from the W3C. First of all, the W3C  
> isn't in charge (HTTP/1.1 is an IETF specification). So, what's relevant  
> is what RFC2616 has to say about GET.

This is a design level issue, an issue of how to apply the WWW
standards, not an issue to be decided by those standards themselves.

> BR, Julian

Reinier Post

Received on Thursday, 25 December 2008 13:41:31 UTC