Hi Chris, thanks for that quick and clear answer,
I really don't want to disturb you on holiday so take your time to answer to
this one.
When I use REST in a gadget (taking care of putting 'allow_anonymous_token'
to true)
It still passes trhought /features/opensocial-rest/restfulcontainer.js
(looks ok) which contains
{{{
this.baseUrl_ + "/rest/jsonBatch?st=" +
encodeURIComponent(shindig.auth.getSecurityToken()),
}}} on line 137
also on this file's header there is a "TODO: THIS IS NOW DEPRECATED. Remove
once PHP implements rpc support"
So I still get the same error
I'm not sure I'm clear with that so I repeat I'm not talking about REST in
general (which I know is working well in shindig) I'm talking about the fact
that gadget can use REST
Maybe I make a mistake somewhere else
Have a good day
Jerome G
On Mon, Dec 29, 2008 at 13:14, Chris Chabot <[email protected]> wrote:
> Hey ben, that would def be possible.
>
> I'm out holidaying around at the moment but I'll reply in more detail
> later in the day/evening when I have a real keyboard again:)
>
> On 12/29/08, Ben Smith <[email protected]> wrote:
> > On a rather un-related note. Can the PHP Shindig container be pointed
> > at an alternative OpenSocial RESTful endpoint?
> >
> > We split our technologies (the ones that are relevant here anyway)
> > between Java for the service layer and PHP for the app/presentation
> > layer. With this in mind, I was wondering whether the PHP
> > implementation would be able to handle the rendering of the container
> > and any OS-Templates along with the distribution of the JS, while
> > using the Java RESTful service layer instead of its own service
> > implementation (similar to how the JS would).
> >
> > I realise this wouldn't be a goal of the PHP implementation, I was
> > just interested in how feasible it would be.
> >
> > Cheers,
> > Ben Smith
> > BBC
> >
> > On 29 Dec 2008, at 11:46, Chris Chabot wrote:
> >
> >> oh ps if you edit shindig/php/config/container.php and set this to
> >> true:
> >> // Allow anonymous (READ) access to the profile information? (aka
> >> REST and
> >> JSON-RPC interfaces)
> >> // setting this to false means you have to be authenticated through
> >> OAuth
> >> to read the data
> >> 'allow_anonymous_token' => true,
> >>
> >> you should be able to make REST requests without having to add
> >> security
> >> tokens or authenticating with OAuth (though those are still required
> >> for any
> >> write actions of course)
> >>
> >> Lastly, it seems by the error your getting it's trying to use the
> >> jsonBatch
> >> endpoint, which isn't REST either but the internal-only protocol we
> >> used
> >> during the 0.7 days.. in other words it's using old crufty 0.7 days
> >> code in
> >> javascript when you set the 'impl' to 'rest'.
> >>
> >> We should probably either remove that switch all together, or hook
> >> it up to
> >> the actual features/opensocial-rest/restfulcontainer.js and make
> >> sure that
> >> that uses the right end-points (/social/rest/<foo> instead of
> >> /social/jsonBatch).
> >>
> >>
> >>
> >> On Mon, Dec 29, 2008 at 12:30 PM, Chris Chabot <[email protected]>
> >> wrote:
> >>
> >>> Shindig (both versions) fully support :
> >>>
> >>>
> http://www.opensocial.org/Technical-Resources/opensocial-spec-v081/restful-protocol
> >>>
> >>> In the case of the comment you copied, it's the POST/PUT action on /
> >>> people
> >>> ... which isn't part of the OpenSocial spec, and the comment
> >>> indicates that
> >>> some day it *could* possibly be added to the spec (like for adding
> >>> friends
> >>> or something), in which case that bit of code will be replaced by
> >>> the proper
> >>> action.
> >>>
> >>> The json-rpc and rest implementations both use the exact same
> >>> implementations btw, just get there through a different code path
> >>> (see
> >>> ApiServlet for the base class, JsonRpcServlet for the json-rpc
> >>> implementation and DataServiceServlet for the REST one). For
> >>> instance a GET
> >>> on /social/rest/people is the same as a json-rpc request with
> >>> {'method':'people.get'}.
> >>>
> >>> So with that hopefully cleared up, I have to admit that I haven't
> >>> used the
> >>> REST gadgets JavaScript code for a long time .. so I have no idea
> >>> what shape
> >>> that is in.. but that's all that the switch in the shindig/js/
> >>> container.js
> >>> file does, switch over the js code that powers the social data
> >>> calls in
> >>> gadgets; If you want to use the REST endpoint in any other situation,
> >>> there's no need to change that config file at all, you can just
> >>> call the
> >>> url's directly.
> >>>
> >>>
> >>>
> >>>
> >>> On Mon, Dec 29, 2008 at 11:51 AM, Jerôme Gangneux <
> >>> [email protected]> wrote:
> >>>
> >>>> I remember that REST was the default protocol for PHP at the
> >>>> beginning,
> >>>> and
> >>>> shindig switch to RPC to uniforms Java and PHP
> >>>> Ok that's cool but does it mean that REST for PHP (and I'm not
> >>>> talking
> >>>> about
> >>>> REST in opensocial here) is abandoned?
> >>>> I see this in the code
> >>>>
> >>>> {{{
> >>>> // in our current implementation this will throw a
> >>>> SocialSPIException since we don't support
> >>>> // adding people/friendships in our API yet, but this might be
> >>>> added
> >>>> some day
> >>>> }}}
> >>>> in /php/src/social/service/RestRequestItem.php line 62
> >>>>
> >>>> and if I switch RPC to REST in container.js (config) it doesn't work
> >>>> anymore
> >>>> getting 500 errors
> >>>> {{{
> >>>> <h1>500 Internal Server Error - Internal Server Error</h1>
> >>>> Invalid or unknown service endpoint: jsonBatch?st=RTN5RVVybW(...)
> >>>> }}}
> >>>>
> >>>> Yes I know, RPC is better etc, but I really need REST for some
> >>>> proof of
> >>>> concept dev
> >>>> what's the plan ?
> >>>>
> >>>> Jerome G
> >>>>
> >>>
> >>>
> >
> >
>
