title: REST Design: What Http verb should be used to retrieve a dynamic resource?
body: <p>I have a scenario in which I have REST API which manages a Resource which we will call Group. A Group contains members and the group resource is dynamic - whenever you retrieve it, you get the latest data (so a query must run server side to update the number of members in a group - in other words, the result of the request is to modify the data, since the results of running the query are stored).</p>
  
  <p>Given a *group_id* it should return a minimal amount of information like</p>
  
  <pre><code>{ 
    group_id: "5t7yu8i9io0op",
    group_name: "That's my name",
    size: 34
  }
  </code></pre>
  
  <p>So a GET to this resource causes the resource to change, since a subsequent GET could return a new value for 'size'. This tells me it is not idempotent and so you should use POST to retrieve this resource. Am I correct in this conclusion?</p>
  
  <p>If I am correct, do you think it is advisable to also provide a GET method that only returns the currently stored data for the group (eg. so the size could be out of date, even the name too). I suppose in this case I should return a last-modified date as one of the fields so that the user knows how up-to-date the resource is and can then elect to use the POST method...but then I am left wondering why would anyone do that, so why not ONLY provide the POST method and forget about GET?</p>
  
  <p>Confused I am!</p>
  
  <p>Thanks in advance.</p>
  
  <p><strong>[EDIT]</strong></p>
  
  <p>@Satish posted a link in his/her answer to the HTTP specs. In section 9.1.1. it ends with this sentence:</p>
  
  <blockquote>
    <p>Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.</p>
  </blockquote>
  
  <p>So in my scenario, the requester does not really care about the side-effect that the value for 'size' is recomputed as a direct result of making the request. They want the group information and it just so happens that to provide accurate, up-to-date group data, the size query must be run in order to update that value. Whilst making the request causes data to change implies this should be a POST, the user did not request that side-effect and so therefore a GET request would be acceptable and more intuitive, would it not? And therefore still be restful according to this sentence.</p>
  
  <p><strong>[2nd EDIT]</strong></p>
  
  <p>@Satish asks a very important question in the comments. So for others who read this I'll explain further about this problem:</p>
  
  <p>Normally you would not run the group query to update its size from a REST request. As members are added or removed from a group, you would update the computed size of that group, store it and then a simple GET request would always return the correct size. However, our situation is more complicated in that a group is only stored as a query definition in ElasticSearch (kind of like a view in an RDBMS). Members do not get added/removed to and from groups. They get added to a much larger set of data (a collection in MongoDB). There are hundreds, potentially thousands, of different 'group definitions' so it is not practical to recompute size for every group when the collection changes. We cannot know when an item is added/removed to/from the collection which groups might change size - you only know by running the group definition who is in that group and what the size is. I hope that clears things up. :)</p>