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
