Thanks Chris, I'll let you all know if I get a chance to try this out!
On 29 Dec 2008, at 22:20, Chris Chabot wrote:
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
