Hey Ben, Here's the bit more detailed version of my response:
Main point of contact between the container, the gadget renderer and the
social api is the security token. Now fortunately the security token works
the same between the PHP and Java versions, hence you can swap PHP and Java
versions as you seem fit, either completely or even partially. As such using
one of the two versions for the rendering/js serving/etc, and the other for
the social api implementation is perfectly doable.
The one thing you do want to keep in mind though is the cross-domain policy
that is the basis of the security model of gadgets (the SNS and shindig
being on different domains prevents the gadget from doing evil things to the
SNS), but also means that the iframe domain (gadget renderer) has to be the
same as the social end point.
So if you want to use PHP for the rendering, and the social API in java,
you'd probably have to:
a) run both on the same machine and use an apache trick like:
ProxyRequests Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass /social http://localhost:8080/social
ProxyPassReverse /social http://localhost:8080/social
b) Do the above, but proxy to a different machine
c) have your load balancer/etc route those requests to a different machine
On Mon, Dec 29, 2008 at 1:06 PM, 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
>>>>
>>>>
>>>
>>>
>
