Shindig should allow RPC requests to pass in GET data, not just POST

[Artem Russakovskii <ar...@plaxo.com>]

Hi everyone,

 

I believe this to be a Shindig bug but need some feedback validating my
thoughts.

 

According to the opensocial RPC spec
http://www.opensocial.org/Technical-Resources/opensocial-spec-v081/rpc-p
rotocol, the following POST and GET RPC requests should be equivalent
and allowed:

 

POST:

POST /rpc HTTP/1.1
Host: api.example.org
Authorization: <Auth token>
Content-Type: application/json
{
  "method" : "people.get",

  "id" : "myself"
  "params" : {

    "userId" : "@me",
    "groupId" : "@self"

  }
}

 

and

 

GET:

http://api.example.org/rpc?method=people.get&id=myself&userId=@me&groupI
d=@self

 

However, I believe Shindig's behavior (at least in PHP) is incorrect
here.

 

When a doGet() function gets called in JsonRpcServlet, it calls
dispatch($request, $token), which expects parameters to be in
$request->params.

 

The problem is, if you compare the RPC spec url above with the JSON
"equivalent", it looks like the url doesn't include a &params GET
variable - instead params like groupId, userId, etc are given as
individual GET params. The shindig PHP code doesn't account for that and
skips them altogether.

 

Supporting the GET version of the spec would make debugging easier as
it's a lot easier to send a GET request than a POST request (in addition
to actually adhering to the spec, of course)

 

Does anyone have any comments confirming this as a bug or otherwise?

 

Thanks,

 

Artem Russakovskii

Plaxo Engineer

Re: Shindig should allow RPC requests to pass in GET data, not just POST

[Chris Chabot <ch...@google.com>]

Hey Artem,

You're quite right, this is indeed part of the spec and currently not
supported in PHP Shindig.

So far every developer who's worked with OpenSocial who's wanted to do GET's
has used the RESTful interface and not the RPC one, so this completely
dropped of my radar since no one complained about it.

For example this:

http://api.example.org/rpc?method=people.get&id=myself&userId=@me&groupI
d=@self<ht...@self>

can be simplified to
http://api.example.org/rest/people/@me/@self

Or if you want to specify a user id:
http://api.example.org/rest/people/User123/@self

Internally RPC and REST requests are represented in the same format and use
the same code path so as far as implementation and testing goes there's no
difference between the RPC and REST call.

In general we prefer the REST interface unless gains can be made through
batching, and RPC+GET removes that benefit since you can only specify a
single call, so it's not very high on my priority list either.

But, patches are welcome so if you have a strong case for why you require
this functionality we'd be happy to accept a patch to fix it up

   -- Chris

On Sat, Dec 5, 2009 at 12:53 AM, Artem Russakovskii <ar...@plaxo.com> wrote:

> Hi everyone,
>
>
>
> I believe this to be a Shindig bug but need some feedback validating my
> thoughts.
>
>
>
> According to the opensocial RPC spec
> http://www.opensocial.org/Technical-Resources/opensocial-spec-v081/rpc-p
> rotocol, the following POST and GET RPC requests should be equivalent
> and allowed:
>
>
>
> POST:
>
> POST /rpc HTTP/1.1
> Host: api.example.org
> Authorization: <Auth token>
> Content-Type: application/json
> {
>  "method" : "people.get",
>
>  "id" : "myself"
>  "params" : {
>
>    "userId" : "@me",
>    "groupId" : "@self"
>
>  }
> }
>
>
>
> and
>
>
>
> GET:
>
> http://api.example.org/rpc?method=people.get&id=myself&userId=@me&groupI
> d=@self<ht...@self>
>
>
>
> However, I believe Shindig's behavior (at least in PHP) is incorrect
> here.
>
>
>
> When a doGet() function gets called in JsonRpcServlet, it calls
> dispatch($request, $token), which expects parameters to be in
> $request->params.
>
>
>
> The problem is, if you compare the RPC spec url above with the JSON
> "equivalent", it looks like the url doesn't include a &params GET
> variable - instead params like groupId, userId, etc are given as
> individual GET params. The shindig PHP code doesn't account for that and
> skips them altogether.
>
>
>
> Supporting the GET version of the spec would make debugging easier as
> it's a lot easier to send a GET request than a POST request (in addition
> to actually adhering to the spec, of course)
>
>
>
> Does anyone have any comments confirming this as a bug or otherwise?
>
>
>
> Thanks,
>
>
>
> Artem Russakovskii
>
> Plaxo Engineer
>
>