Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Can HTTP GET be used if there are small side-effects?

Tags:

As far as I understand, GET has to be idempotent - it cannot change anything in the system and repeating it should always return the same unless something else changed the state of the application.

Problem is, on my website, there should be a lot of little changes based on whether some content has been already seen before by the user. I mean, like notifications, new message alerts, content sorting based on whether user saw it or not, how many users saw the content counters... For example when user clicks on notification, the notification should disappear from his notification panel and never be seen there again, so it changes something - state of the notification, but I can press F5 as many times as I want and it always returns the same page with same info, same buttons etc.

Can I ignore this kind of side-effect as too small and I can use GET or do I have to make most links and buttons on the website use POST like I do with links and buttons which lead to more "serious" changes? I do that by making forms around each of them with those links as form actions and original buttons as submit buttons of the form which seems a little messy to me and I don't want it almost everywhere (or is there a better way?).

like image 718
Jan Avatar asked Dec 28 '16 09:12

Jan


People also ask

Can HTTP GET have side effects?

The HTTP GET method isn't supposed to have side effects. It's considered read-only for retrieving data. It is generally considered a bad practice to implement any type of write behavior (the things that will have side effects) in an HTTP GET.

Which type of HTTP has side effects?

The POST method submits an entity to the specified resource, often causing a change in state or side effects on the server.

When would you use a GET request vs a POST request?

'POST' has no size restrictions for transmitted data, whilst 'GET' is limited to 2048 characters.


1 Answers

This can be tackled from several points of view, I'll illuminate it from this angle:

The end result here is always the same, hence the request is idempotent.

The user visits the URL, the end result is that the notifications are cleared. They can visit the page again and again, the end result is that the notifications are cleared. They're not going to get an error message because the notifications have been previously cleared (that would not be idempotent). Yes, they will see different content each time they visit the page, but nothing says that the page content must be identical each time the resource is requested (that would put half the web in a bind).

Contrast that with a POST request to /questions (which creates a new question, for example): each time you repeat that POST request, a completely new resource is being created. You POST once, and /questions/12345 is being created. You repeat the same request, /questions/12346 is being created. That is not idempotent.

No, you do not need to make all those requests into POST requests.

like image 52
deceze Avatar answered Sep 23 '22 17:09

deceze