You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@click.apache.org by georgex <ge...@yahoo.com> on 2010/03/29 12:18:10 UTC
HTTP GET should not change the data on the server?
I read and hear everywhere that HTTP GET should not change the data on the
server.
(Only POST, or if a RESt style is used, than POST, PUT (for update), and
DELETE).
If I run however the click-examples with FireBug, than I see that delete
operations happen with a HTTP GET :(.
thanks,
George.
--
View this message in context: http://n2.nabble.com/HTTP-GET-should-not-change-the-data-on-the-server-tp4817128p4817128.html
Sent from the click-development mailing list archive at Nabble.com.
Re: HTTP GET should not change the data on the server?
Posted by Bob Schellink <sa...@gmail.com>.
Sorry, sent to wrong list.
bob
On 29/03/2010 09:39 PM, Bob Schellink wrote:
> One of the main reasons to have replayable GET requests is so you can
> cache the content for high access websites. If you are developing a
> non-public low traffic website there is no reason to cache the result
> and no reason not to take advantage of the simplicity of GET requests.
>
> The Click example could be implemented with GET or POST requests,
> nothing in Click stops you from using one or the other. For example,
> instead of having a "delete" link, the example could be implemented by
> having a "Delete" button on the edit-customer.htm page. However the user
> now has to select the customer before deleting it. Alternatively the
> table could be wrapped in a Form and checkboxes used to select which row
> to delete, ala gmail.
>
> kind regards
>
> bob
>
> On 29/03/2010 09:18 PM, georgex wrote:
>>
>> I read and hear everywhere that HTTP GET should not change the data on
>> the
>> server.
>> (Only POST, or if a RESt style is used, than POST, PUT (for update), and
>> DELETE).
>>
>> If I run however the click-examples with FireBug, than I see that delete
>> operations happen with a HTTP GET :(.
>>
>> thanks,
>> George.
>
>
Re: HTTP GET should not change the data on the server?
Posted by Bob Schellink <sa...@gmail.com>.
One of the main reasons to have replayable GET requests is so you can cache the content for high
access websites. If you are developing a non-public low traffic website there is no reason to cache
the result and no reason not to take advantage of the simplicity of GET requests.
The Click example could be implemented with GET or POST requests, nothing in Click stops you from
using one or the other. For example, instead of having a "delete" link, the example could be
implemented by having a "Delete" button on the edit-customer.htm page. However the user now has to
select the customer before deleting it. Alternatively the table could be wrapped in a Form and
checkboxes used to select which row to delete, ala gmail.
kind regards
bob
On 29/03/2010 09:18 PM, georgex wrote:
>
> I read and hear everywhere that HTTP GET should not change the data on the
> server.
> (Only POST, or if a RESt style is used, than POST, PUT (for update), and
> DELETE).
>
> If I run however the click-examples with FireBug, than I see that delete
> operations happen with a HTTP GET :(.
>
> thanks,
> George.
Re: HTTP GET should not change the data on the server?
Posted by georgex <ge...@yahoo.com>.
One of the main reasons to have replayable GET requests is so you can cache
the content for high
access websites. If you are developing a non-public low traffic website
there is no reason to cache
the result and no reason not to take advantage of the simplicity of GET
requests.
I understand the cache vs non-cache thing, but what about Browser plug-ins
like GoogleToolbar, or other plug-ins that do (pre-)fetching or spidering?
Bob Schellink wrote:
>
> The Click example could be implemented with GET or POST requests, nothing
> in Click stops you from
> using one or the other.
>
Users usually follow the click-examples, documentation and the best
practices :).
Bob Schellink wrote:
>
> For example, instead of having a "delete" link, the example could be
> implemented by having a "Delete" button on the edit-customer.htm page.
> However the user now has to
> select the customer before deleting it. Alternatively the table could be
> wrapped in a Form and
> checkboxes used to select which row to delete, ala gmail.
>
This looks a little bit complicated. A simple link is indeed much simpler
than a button - even when considering the styling only.
Wouldn't be worth having something like SubmitLink but without the trouble
with a From object? e.g. To have a Link that allows POST functionality too?
I saw that Basecamp is doing this for their Delete operations - it's a link
on the page, but when clicked, dynamically adds a unique small Form (to have
a POST for delete - but to keep the simplicity of the link usage) - I
suppose their server translates this transparently too.
thanks,
George.
--
View this message in context: http://n2.nabble.com/HTTP-GET-should-not-change-the-data-on-the-server-tp4817128p4817484.html
Sent from the click-development mailing list archive at Nabble.com.
Re: HTTP GET should not change the data on the server?
Posted by Bob Schellink <sa...@gmail.com>.
One of the main reasons to have replayable GET requests is so you can cache the content for high
access websites. If you are developing a non-public low traffic website there is no reason to cache
the result and no reason not to take advantage of the simplicity of GET requests.
The Click example could be implemented with GET or POST requests, nothing in Click stops you from
using one or the other. For example, instead of having a "delete" link, the example could be
implemented by having a "Delete" button on the edit-customer.htm page. However the user now has to
select the customer before deleting it. Alternatively the table could be wrapped in a Form and
checkboxes used to select which row to delete, ala gmail.
kind regards
bob
On 29/03/2010 09:18 PM, georgex wrote:
>
> I read and hear everywhere that HTTP GET should not change the data on the
> server.
> (Only POST, or if a RESt style is used, than POST, PUT (for update), and
> DELETE).
>
> If I run however the click-examples with FireBug, than I see that delete
> operations happen with a HTTP GET :(.
>
> thanks,
> George.