W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2012

Re: add GETAJAX verb/method in http protocol

From: J Ross Nicoll <jrn@jrn.me.uk>
Date: Tue, 22 May 2012 19:54:15 +0100
Message-ID: <4FBBE0D7.4040209@jrn.me.uk>
To: ietf-http-wg@w3.org

I'm not sure this necessarily makes sense as a separate method; you're 
still taking the same action (getting a resource), it's just the 
presentation that differs. I tend to use query parameters to indicate 
which parts of a resource I want (and an Accept header to indicate I'm 
wanting the response as JSON/XML), is that a reason that doesn't suit?


On 22/05/2012 14:47, Christian RIGONI wrote:
> Hello everybody,
> I could not find this possibility in the mailing lists, so I would 
> like to bring up this topic.
> By working on html page developpement, I remarked that very often (but 
> not always of course), ajax request correspond to information that are 
> relative to an html page.
> For example, lets define the page http://www.site.com/page.html on a 
> server.
> The first http verb used for this page is obviously GET.
> Then the page is displayed by the navigator on the client.
> Now, suppose the user modify an element of the page. It can be useful 
> to send a http GETAJAX request to http://www.site.com/page.html in 
> order to get the information corresponding to the new element modified 
> by the user.
> Actually the problem is adressed by sending a http GET to another 
> page, for example www.site.com/page_ajax.html. But may be it can be 
> useful to send a http GETAJAX to the page http://www.site.com/page.html.
> Another thing which can be usefull, the same page 
> http://www.site.com/page.html may have several http ajax request to 
> process. So an ajax_id can be added to the http GETAJAX to 
> differentiate the ajax requests.
> I hope this request will be helpfull for you and other people.
> Sincerely.
> _Christian RIGONI_
Received on Tuesday, 22 May 2012 18:55:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:02 UTC