Mark,

Given the way things are currently defined in the API's, I have little doubt that batching helps performance, but that's not really the point I'm trying to make...

Consider this:
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-743.

The salient points: "People perceive a need for batch operations because they don’t understand the scope of resources... [t]he same resource state can be overlayed by multiple resources, just as an XML document can be represented as a sequence of bytes or a tree of individually addressable nodes. Likewise, a single resource can be the equivalent of a database stored procedure, with the power to abstract state changes over any number of storage items... If you find yourself in need of a batch operation, then most likely you just haven’t defined enough resources."

Let's look at the case you brought up in your earlier message. You said: "So you get a collection of users, batch up the ones you want to know more about and away you go."

My question to this is: why do we need a "batch" request?

Consider.. this is what a current RPC batch request currently looks like in the RPC model..

 POST /rpc HTTP/1.1  Host: api.example.org  Authorization: hh5s93j4hdidpola  Content-Type: application/json  [    {      "method" : "people.get",      "id" : "myself",      "params" : {        "userId" : "@me",        "groupId" : "@self"      }    },    {      "method" : "people.get",      "id" : "myfriends",      "params" : {        "userId" : "@me",        "groupId" : "@friends"      }    }  ]

The thing that strikes me as very odd about this is.. why isn't it just...

 POST /rpc HTTP/1.1  Host: api.example.org  Authorization: hh5s93j4hdidpola  Content-Type: application/json    {      "method" : "people.get",      "id" : "myself",      "params" : {        "userId" : "@me",        "groups": ["@self","@friends"]        }      ]    }

Or even better...

 GET /people/@me/@self,@friends HTTP/1.1  Host: api.example.org  Authorization: hh5s93j4hdidpola

From everything that I can see, the *ONLY* reason batching is required here is because of how the people.get operation is currently defined. With either of the two alternatives I suggest, the requirement for a batch request completely disappears. The GET option would be WAY more efficient than the POST /rpc with a batch request option could ever be. Period.

In your note you also said that another case "is to retrieve more information about the "stuff" a user has, e.g. blogs, documents, discussions, etc. " ... to which the natural question is: Well, why isn't there a single operation that would allow you to retrieve this information? I'd argue, as Roy suggests in the quote above, the only reason you'd need to batch requests to get the data you need is because we have created enough resources. We can take the time now to define those missing resources, and we can take the time to define something like the Persistent Query Service and better search and filter capabilities to completely eliminate the need for batching requests altogether.

We simply need to define new resources that provide all the information we need.

If you still think batching is an absolute requirement, let's put it to a test... show me a use case that absolutely requires batch request capability and if I'm not able to demonstrate that the same case can be implemented more efficiently without batching, I'll concede on the point.

On Tue, Feb 7, 2012 at 5:50 PM, Mark W. <weit...@gmail.com> wrote: