1

This is a generic question about GET method.

Imagine I need to store the last pagination size selected by the user:

+-------------+   +-------------+    +--------------------+    +----------+
| Size change |-> | GET request | -> | Server store pref. | -> | Response | 
+-------------+   +-------------+    +--------------------+    +----------+

Browsing a list of products is of course a GET request and changing the paging size is a GET request too (we change only the size parameter):

<ul>
    <li><a href="/catalog/browse/size=10&page=1">size 10</a></li>
    <li><a href="/catalog/browse/size=25&page=1">size 25</a></li>
    <li><a href="/catalog/browse/size=50&page=1">size 50</a></li>
</ul>

Every time the user changes the size I need to store the new size in my backend.

How to deal the the fact the GET should not change the state? Issuing a query (thus changing the state of the application) fees so wrong to me. Is there any alternative?

GET Requests a representation of the specified resource. Requests using GET should only retrieve data and should have no other effect.

gremo
  • 45,925
  • 68
  • 233
  • 380
  • Why do you need to store the new size in your backend? Isn't the information you're given in the URL (page number and size) enough to return the correct result? – Pekka Jun 20 '15 at 09:10
  • @Pekka웃 because the system should remember the last selected paging size for each user. So next time you login the pref. is restored. – gremo Jun 20 '15 at 09:11
  • 1
    How would storing the size make it non-idempotent? If I set the size to 50 twice, the size will be set to 50, just as if I set the size once. So it's idempotent. It wouldn't be idempotent if, for example, you incremented the size. Because incrementing twice doesn't lead to the same result as incrementing once. – JB Nizet Jun 20 '15 at 09:12
  • @JBNizet idempotent in the sense that application state should change with A GET request. – gremo Jun 20 '15 at 09:13
  • @gremo that's the problem. Idempotent doesn't mean that state can't change. That's what you **think** it means. – JB Nizet Jun 20 '15 at 09:13
  • @JBNizet so changing the state with a GET request is allowed in the sense of REST? Thanks for clarifying this. – gremo Jun 20 '15 at 09:14
  • 1
    That's not what he said. It's not really RESTful to have a per-user page size setting (implying some sort of session in the background). It seems more correct to simply always pass a page number and page size... – Pekka Jun 20 '15 at 09:16
  • @Pekka웃 i slightly changed the question to reflect what I really mean. – gremo Jun 20 '15 at 09:19
  • I think there is a misunderstanding here about what REST is. A RESTful API by definition doesn't have a session connected to the requesting user in which something like a preferred page size can be stored. Possibly related: http://stackoverflow.com/questions/3105296/if-rest-applications-are-supposed-to-be-stateless-how-do-you-manage-sessions – Pekka Jun 20 '15 at 09:21
  • I disagree with Pekka. Returning a reponse that depends on who is sending the request is perfectly acceptable. And a server can have state, including state that is related to the connected user. I'm just saying that changing state as part of a GET request is perfectly valid, as long as it's idempotent. And it is in this case. – JB Nizet Jun 20 '15 at 09:25

0 Answers0