You are viewing a plain text version of this content. The canonical link for it is here.
Posted to photark-dev@incubator.apache.org by Umashanthi Pavalanathan <um...@gmail.com> on 2011/07/08 10:58:13 UTC
REST integration for back-end functionality in photark-rest branch
Hi Devs,
As you know I am working on adding social features to PhotArk in the rest
branch.
To proceed further with the implementation, I have to add the social
features in the UI. When working on this, I came across the requirement of
exposing the back-end functionalities as REST services. As you know,
implementation in the trunk uses Apache Tuscany to integrate and expose the
functionality as JSON-RPC. Similarly in the rest branch we have the
requirement of exposing the back-end functionality as REST services. For
this purpose, I looked into three options:
(1) Apache Shindig [0]
(2) Apache Tuscany [1]
(3) Apache Wookie [2]
As we have discussed earlier in the mailing list [3], Apache Shindig
provides a reference implementation for the OpenSocial specification and
provide JSON-RPC & REST APIs. But these APIs are only limited to the
concepts/services in the OpenSocial specification and currently there seems
to be no plans for extending further. So, using Apache Shindig, we can
integrate the back-end social features as REST services; but it is only
limited to this purpose. Since in the context of PhotArk, there are several
other functionalities/concepts like Albums, etc, using Shindig will not
cater for all the requirements.
On the other hand, Apache Tuscany, can be used to expose the functionalities
as REST services without any limitations and it's usage in the PhotArk trunk
assures that it can satisfy all the requirements in PhotArk.
Apaceh Wookie also provides REST API. But it is particularly designed to
facilitate building widgets. Similar to Shindig, Wookie also has limited
support for converting all the functionalities in PhotArk into REST
services. Even though Wookie has the support for UI widgets, I do not see
any plans to make PhotArk as a widget based application in the near future.
So the REST integration facility provided by Wookie is limited in the
context of PhotArk.
After analyzing these three options, Apache Tuscany seems to be promising
for me, to support all the requirements of PhotArk, related to exposing REST
services.
I kindly invite you all to proceed further with this discussion. Your
valuable input to this discussion is highly appreciated.
Looking forward to hear from you all.
[0] http://shindig.apache.org/
[1] http://tuscany.apache.org/
[2] http://incubator.apache.org/wookie/
[3]
http://www.mail-archive.com/photark-dev@incubator.apache.org/msg01141.html
Thanks,
~Umashanthi
Re: REST integration for back-end functionality in photark-rest branch
Posted by Umashanthi Pavalanathan <um...@gmail.com>.
Hi Devs,
I have attached a sample composite file for the PersonService to the JIRA
[0]. Please be kind enough to let me know the validity of it so that I can
improve and add for other services.
[0]
https://issues.apache.org/jira/secure/attachment/12488001/personservice.composite
Thanks,
~Umashanthi
On Thu, Jul 21, 2011 at 12:23 PM, Umashanthi Pavalanathan <
umashanthip@gmail.com> wrote:
>
>
> On Thu, Jul 21, 2011 at 12:19 PM, Luciano Resende <lu...@gmail.com>wrote:
>
>> On Wed, Jul 20, 2011 at 11:43 PM, Umashanthi Pavalanathan
>> <um...@gmail.com> wrote:
>> >>
>> >> Sounds good, and I have couple little questions :
>> >>
>> >> What can be an activity ?
>> >>
>> >
>> > Activity can be any action of a user. eg: Adding a new album, tagging a
>> > photo, commenting on a photo, rating etc.
>> > So, to make use of this concept of "activity", when a user performs such
>> > actions in PhotArk, they should be recorded as "activities" of that
>> user.
>> >
>>
>> Ok, so most of the time activities will be generated by the PhotArk
>> system when user interact with the application (e.g. new album, new
>> comment, etc)
>>
>
> +1
>
>
>>
>>
>> >> What can be an AppData ?
>> >>
>> >
>> > AppData is actually any name-value pair data we want to store for a
>> user.
>> > For eg if the user have done any configurations(i.e: property settings),
>> > those details can be saved as name-value pairs. I don't see any usage of
>> > this in PhotArk currently; but believe that this can be utilized in
>> future.
>> >
>>
>> +1
>>
>> >
>> >> What's the scenario for updating a "activity" or "appdata"... just
>> >> curious as other places such as Twitter, Facebook seem to only allow
>> >> updates/delete and not really updates for some performance reasons.
>> >>
>> >
>> > Yes, true. But in the case of appdata, updating an appdata entry will be
>> OK
>> > I guess.
>> >
>> > With respect to "activity" what I had in mind is updating a "comment" on
>> a
>> > photo or something like that. But even that can be recorded as another
>> > "activity". So, the "update" might not be used considering performance
>> > issues as you said; but I added it to have a complete set of operations
>> on
>> > "activity".
>> >
>> > Hope I have answered the questions you had.
>> >
>>
>> Yes, all answered.
>>
>> It seems that these are going to be most of the time used as read only
>> (at least for the scenarios we currently going to have).. this might
>> help simplify the rest api if needed.
>>
>
> OK; I will think about that and discuss further here.
>
>
> Thanks,
> ~Umashanthi
>
>
>>
>>
>>
>>
>> --
>> Luciano Resende
>> http://people.apache.org/~lresende
>> http://twitter.com/lresende1975
>> http://lresende.blogspot.com/
>>
>
>
Re: REST integration for back-end functionality in photark-rest branch
Posted by Umashanthi Pavalanathan <um...@gmail.com>.
On Thu, Jul 21, 2011 at 12:19 PM, Luciano Resende <lu...@gmail.com>wrote:
> On Wed, Jul 20, 2011 at 11:43 PM, Umashanthi Pavalanathan
> <um...@gmail.com> wrote:
> >>
> >> Sounds good, and I have couple little questions :
> >>
> >> What can be an activity ?
> >>
> >
> > Activity can be any action of a user. eg: Adding a new album, tagging a
> > photo, commenting on a photo, rating etc.
> > So, to make use of this concept of "activity", when a user performs such
> > actions in PhotArk, they should be recorded as "activities" of that user.
> >
>
> Ok, so most of the time activities will be generated by the PhotArk
> system when user interact with the application (e.g. new album, new
> comment, etc)
>
+1
>
>
> >> What can be an AppData ?
> >>
> >
> > AppData is actually any name-value pair data we want to store for a user.
> > For eg if the user have done any configurations(i.e: property settings),
> > those details can be saved as name-value pairs. I don't see any usage of
> > this in PhotArk currently; but believe that this can be utilized in
> future.
> >
>
> +1
>
> >
> >> What's the scenario for updating a "activity" or "appdata"... just
> >> curious as other places such as Twitter, Facebook seem to only allow
> >> updates/delete and not really updates for some performance reasons.
> >>
> >
> > Yes, true. But in the case of appdata, updating an appdata entry will be
> OK
> > I guess.
> >
> > With respect to "activity" what I had in mind is updating a "comment" on
> a
> > photo or something like that. But even that can be recorded as another
> > "activity". So, the "update" might not be used considering performance
> > issues as you said; but I added it to have a complete set of operations
> on
> > "activity".
> >
> > Hope I have answered the questions you had.
> >
>
> Yes, all answered.
>
> It seems that these are going to be most of the time used as read only
> (at least for the scenarios we currently going to have).. this might
> help simplify the rest api if needed.
>
OK; I will think about that and discuss further here.
Thanks,
~Umashanthi
>
>
>
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>
Re: REST integration for back-end functionality in photark-rest branch
Posted by Luciano Resende <lu...@gmail.com>.
On Wed, Jul 20, 2011 at 11:43 PM, Umashanthi Pavalanathan
<um...@gmail.com> wrote:
>>
>> Sounds good, and I have couple little questions :
>>
>> What can be an activity ?
>>
>
> Activity can be any action of a user. eg: Adding a new album, tagging a
> photo, commenting on a photo, rating etc.
> So, to make use of this concept of "activity", when a user performs such
> actions in PhotArk, they should be recorded as "activities" of that user.
>
Ok, so most of the time activities will be generated by the PhotArk
system when user interact with the application (e.g. new album, new
comment, etc)
>> What can be an AppData ?
>>
>
> AppData is actually any name-value pair data we want to store for a user.
> For eg if the user have done any configurations(i.e: property settings),
> those details can be saved as name-value pairs. I don't see any usage of
> this in PhotArk currently; but believe that this can be utilized in future.
>
+1
>
>> What's the scenario for updating a "activity" or "appdata"... just
>> curious as other places such as Twitter, Facebook seem to only allow
>> updates/delete and not really updates for some performance reasons.
>>
>
> Yes, true. But in the case of appdata, updating an appdata entry will be OK
> I guess.
>
> With respect to "activity" what I had in mind is updating a "comment" on a
> photo or something like that. But even that can be recorded as another
> "activity". So, the "update" might not be used considering performance
> issues as you said; but I added it to have a complete set of operations on
> "activity".
>
> Hope I have answered the questions you had.
>
Yes, all answered.
It seems that these are going to be most of the time used as read only
(at least for the scenarios we currently going to have).. this might
help simplify the rest api if needed.
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: REST integration for back-end functionality in photark-rest branch
Posted by Umashanthi Pavalanathan <um...@gmail.com>.
On Thu, Jul 21, 2011 at 11:42 AM, Luciano Resende <lu...@gmail.com>wrote:
> On Wed, Jul 20, 2011 at 10:56 PM, Umashanthi Pavalanathan
> <um...@gmail.com> wrote:
> > Hi Devs,
> >
> > On Tue, Jul 12, 2011 at 2:33 AM, Umashanthi Pavalanathan <
> > umashanthip@gmail.com> wrote:
> >
> >>
> >>
> >> On Mon, Jul 11, 2011 at 9:56 AM, Umashanthi Pavalanathan <
> >> umashanthip@gmail.com> wrote:
> >>
> >>> Hi Devs,
> >>>
> >>> I have come up with the REST URI scheme for the Person and relationship
> >>> related Social concepts.
> >>> I used the PhotArk REST API [0] and the OpenSocial REST API [1] as
> >>> references for this purpose.
> >>>
> >>> The following are my initial thoughts. You feedback & suggestions are
> >>> welcomed.
> >>>
> >>> (1) Get a Person
> >>>
> >>> REST-HTTP-Method = "GET"
> >>>
> >>> REST-URI-Fragment = /people/{userId}/@self
> >>>
> >>>
> >>> (2) Get a Person's friends
> >>>
> >>> REST-HTTP-Method = "GET"
> >>> REST-URI-Fragment = /people/{userId}/@friends
> >>>
> >>>
> >>> (3) Get all Persons
> >>>
> >>> REST-HTTP-Method = "GET"
> >>> REST-URI-Fragment = /people
> >>>
> >>>
> >>> (4) Update a Person
> >>>
> >>> REST-HTTP-Method = "POST"
> >>> REST-URI-Fragment = /people/{userId}
> >>>
> >>>
> >> correction:
> >> Update a Person
> >> REST-HTTP-Method = "PUT"
> >> REST-URI-Fragment = /people/{userId}
> >>
> >>
> >>> (5) Delete a person
> >>>
> >>> REST-HTTP-Method = "DELETE"
> >>> REST-URI-Fragment = /people/{userId}
> >>>
> >>>
> >>> (6) Create a Relationship request
> >>>
> >>> REST-HTTP-Method = "POST"
> >>> REST-URI-Fragment = "/people/realtionship/{ownerId}/{viewerId}
> >>>
> >>>
> >>> (7) Create a Relationship
> >>>
> >>> REST-HTTP-Method = "POST"
> >>> REST-URI-Fragment = "/people/relationship/{ownerId}/{viewerId}
> >>>
> >>>
> >>> (8) Get Relationship between two users
> >>>
> >>> REST-HTTP-Method = "GET"
> >>> REST-URI-Fragment = "/people/relationship/{ownerId}/{viewerId}
> >>>
> >>>
> >>> (9) Remove Relationship between two users
> >>>
> >>> REST-HTTP-Method = "DELETE"
> >>> REST-URI-Fragment = "/people/realtionship/{ownerId}/{viewerId}
> >>>
> >>>
> >
> > I have come up with the URI scheme for Activity and AppData related
> > concepts.
> > I would like to get your feedback & suggestions regarding this so that I
> can
> > proceed with the REST-integration of ActivityService and AppDataService.
> >
> > *Activity Related Operations:*
> >
> > (1) Save an Activity
> > REST-HTTP-Method = "POST"
> > REST-URI-Fragment = /people/{userId}/activities
> >
> > (2) Create an Activity
> > REST-HTTP-Method = "GET"
> > REST-URI-Fragment = /people/{userId}/activities
> >
> > (3) Update an Activity
> > REST-HTTP-Method = "PUT"
> > REST-URI-Fragment = /people/{userId}/activities
> >
> > (4) Delete an Activity
> > REST-HTTP-Method = "DELETE"
> > REST-URI-Fragment = people/{userId}/activities/{activityId}
> >
> > (5) Get an Activity
> > REST-HTTP-Method = "GET"
> > REST-URI-Fragment = /people/{userId}/activities/{activityId}
> >
> > (6) Get Activities for given activity IDs with optional filters
> >
> > (7) Get Activities for given user IDs with optional filters
> >
> > *AppData Related Operations:*
> >
> > (1) Get AppData
> > REST-HTTP-Method = "GET"
> > REST-URI-Fragment = /people/{userId}/appdata/{appId}
> >
> > (2) Create AppData
> > REST-HTTP-Method = "POST"
> > REST-URI-Fragment = /people/{userId}/appdata/{appId}
> >
> > (3) Update AppData
> > REST-HTTP-Method = "PUT"
> > REST-URI-Fragment = /people/{userId}/appdata/{appId}
> >
> > (4) Delete AppData
> > REST-HTTP-Method = "DELETE"
> > REST-URI-Fragment = /people/{userId}/appdata/{appId}
> >
> >
>
> Sounds good, and I have couple little questions :
>
> What can be an activity ?
>
Activity can be any action of a user. eg: Adding a new album, tagging a
photo, commenting on a photo, rating etc.
So, to make use of this concept of "activity", when a user performs such
actions in PhotArk, they should be recorded as "activities" of that user.
> What can be an AppData ?
>
AppData is actually any name-value pair data we want to store for a user.
For eg if the user have done any configurations(i.e: property settings),
those details can be saved as name-value pairs. I don't see any usage of
this in PhotArk currently; but believe that this can be utilized in future.
> What's the scenario for updating a "activity" or "appdata"... just
> curious as other places such as Twitter, Facebook seem to only allow
> updates/delete and not really updates for some performance reasons.
>
Yes, true. But in the case of appdata, updating an appdata entry will be OK
I guess.
With respect to "activity" what I had in mind is updating a "comment" on a
photo or something like that. But even that can be recorded as another
"activity". So, the "update" might not be used considering performance
issues as you said; but I added it to have a complete set of operations on
"activity".
Hope I have answered the questions you had.
Thanks,
~Umashanthi
>
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>
Re: REST integration for back-end functionality in photark-rest branch
Posted by Luciano Resende <lu...@gmail.com>.
On Wed, Jul 20, 2011 at 10:56 PM, Umashanthi Pavalanathan
<um...@gmail.com> wrote:
> Hi Devs,
>
> On Tue, Jul 12, 2011 at 2:33 AM, Umashanthi Pavalanathan <
> umashanthip@gmail.com> wrote:
>
>>
>>
>> On Mon, Jul 11, 2011 at 9:56 AM, Umashanthi Pavalanathan <
>> umashanthip@gmail.com> wrote:
>>
>>> Hi Devs,
>>>
>>> I have come up with the REST URI scheme for the Person and relationship
>>> related Social concepts.
>>> I used the PhotArk REST API [0] and the OpenSocial REST API [1] as
>>> references for this purpose.
>>>
>>> The following are my initial thoughts. You feedback & suggestions are
>>> welcomed.
>>>
>>> (1) Get a Person
>>>
>>> REST-HTTP-Method = "GET"
>>>
>>> REST-URI-Fragment = /people/{userId}/@self
>>>
>>>
>>> (2) Get a Person's friends
>>>
>>> REST-HTTP-Method = "GET"
>>> REST-URI-Fragment = /people/{userId}/@friends
>>>
>>>
>>> (3) Get all Persons
>>>
>>> REST-HTTP-Method = "GET"
>>> REST-URI-Fragment = /people
>>>
>>>
>>> (4) Update a Person
>>>
>>> REST-HTTP-Method = "POST"
>>> REST-URI-Fragment = /people/{userId}
>>>
>>>
>> correction:
>> Update a Person
>> REST-HTTP-Method = "PUT"
>> REST-URI-Fragment = /people/{userId}
>>
>>
>>> (5) Delete a person
>>>
>>> REST-HTTP-Method = "DELETE"
>>> REST-URI-Fragment = /people/{userId}
>>>
>>>
>>> (6) Create a Relationship request
>>>
>>> REST-HTTP-Method = "POST"
>>> REST-URI-Fragment = "/people/realtionship/{ownerId}/{viewerId}
>>>
>>>
>>> (7) Create a Relationship
>>>
>>> REST-HTTP-Method = "POST"
>>> REST-URI-Fragment = "/people/relationship/{ownerId}/{viewerId}
>>>
>>>
>>> (8) Get Relationship between two users
>>>
>>> REST-HTTP-Method = "GET"
>>> REST-URI-Fragment = "/people/relationship/{ownerId}/{viewerId}
>>>
>>>
>>> (9) Remove Relationship between two users
>>>
>>> REST-HTTP-Method = "DELETE"
>>> REST-URI-Fragment = "/people/realtionship/{ownerId}/{viewerId}
>>>
>>>
>
> I have come up with the URI scheme for Activity and AppData related
> concepts.
> I would like to get your feedback & suggestions regarding this so that I can
> proceed with the REST-integration of ActivityService and AppDataService.
>
> *Activity Related Operations:*
>
> (1) Save an Activity
> REST-HTTP-Method = "POST"
> REST-URI-Fragment = /people/{userId}/activities
>
> (2) Create an Activity
> REST-HTTP-Method = "GET"
> REST-URI-Fragment = /people/{userId}/activities
>
> (3) Update an Activity
> REST-HTTP-Method = "PUT"
> REST-URI-Fragment = /people/{userId}/activities
>
> (4) Delete an Activity
> REST-HTTP-Method = "DELETE"
> REST-URI-Fragment = people/{userId}/activities/{activityId}
>
> (5) Get an Activity
> REST-HTTP-Method = "GET"
> REST-URI-Fragment = /people/{userId}/activities/{activityId}
>
> (6) Get Activities for given activity IDs with optional filters
>
> (7) Get Activities for given user IDs with optional filters
>
> *AppData Related Operations:*
>
> (1) Get AppData
> REST-HTTP-Method = "GET"
> REST-URI-Fragment = /people/{userId}/appdata/{appId}
>
> (2) Create AppData
> REST-HTTP-Method = "POST"
> REST-URI-Fragment = /people/{userId}/appdata/{appId}
>
> (3) Update AppData
> REST-HTTP-Method = "PUT"
> REST-URI-Fragment = /people/{userId}/appdata/{appId}
>
> (4) Delete AppData
> REST-HTTP-Method = "DELETE"
> REST-URI-Fragment = /people/{userId}/appdata/{appId}
>
>
Sounds good, and I have couple little questions :
What can be an activity ?
What can be an AppData ?
What's the scenario for updating a "activity" or "appdata"... just
curious as other places such as Twitter, Facebook seem to only allow
updates/delete and not really updates for some performance reasons.
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: REST integration for back-end functionality in photark-rest branch
Posted by Umashanthi Pavalanathan <um...@gmail.com>.
Hi Devs,
On Tue, Jul 12, 2011 at 2:33 AM, Umashanthi Pavalanathan <
umashanthip@gmail.com> wrote:
>
>
> On Mon, Jul 11, 2011 at 9:56 AM, Umashanthi Pavalanathan <
> umashanthip@gmail.com> wrote:
>
>> Hi Devs,
>>
>> I have come up with the REST URI scheme for the Person and relationship
>> related Social concepts.
>> I used the PhotArk REST API [0] and the OpenSocial REST API [1] as
>> references for this purpose.
>>
>> The following are my initial thoughts. You feedback & suggestions are
>> welcomed.
>>
>> (1) Get a Person
>>
>> REST-HTTP-Method = "GET"
>>
>> REST-URI-Fragment = /people/{userId}/@self
>>
>>
>> (2) Get a Person's friends
>>
>> REST-HTTP-Method = "GET"
>> REST-URI-Fragment = /people/{userId}/@friends
>>
>>
>> (3) Get all Persons
>>
>> REST-HTTP-Method = "GET"
>> REST-URI-Fragment = /people
>>
>>
>> (4) Update a Person
>>
>> REST-HTTP-Method = "POST"
>> REST-URI-Fragment = /people/{userId}
>>
>>
> correction:
> Update a Person
> REST-HTTP-Method = "PUT"
> REST-URI-Fragment = /people/{userId}
>
>
>> (5) Delete a person
>>
>> REST-HTTP-Method = "DELETE"
>> REST-URI-Fragment = /people/{userId}
>>
>>
>> (6) Create a Relationship request
>>
>> REST-HTTP-Method = "POST"
>> REST-URI-Fragment = "/people/realtionship/{ownerId}/{viewerId}
>>
>>
>> (7) Create a Relationship
>>
>> REST-HTTP-Method = "POST"
>> REST-URI-Fragment = "/people/relationship/{ownerId}/{viewerId}
>>
>>
>> (8) Get Relationship between two users
>>
>> REST-HTTP-Method = "GET"
>> REST-URI-Fragment = "/people/relationship/{ownerId}/{viewerId}
>>
>>
>> (9) Remove Relationship between two users
>>
>> REST-HTTP-Method = "DELETE"
>> REST-URI-Fragment = "/people/realtionship/{ownerId}/{viewerId}
>>
>>
I have come up with the URI scheme for Activity and AppData related
concepts.
I would like to get your feedback & suggestions regarding this so that I can
proceed with the REST-integration of ActivityService and AppDataService.
*Activity Related Operations:*
(1) Save an Activity
REST-HTTP-Method = "POST"
REST-URI-Fragment = /people/{userId}/activities
(2) Create an Activity
REST-HTTP-Method = "GET"
REST-URI-Fragment = /people/{userId}/activities
(3) Update an Activity
REST-HTTP-Method = "PUT"
REST-URI-Fragment = /people/{userId}/activities
(4) Delete an Activity
REST-HTTP-Method = "DELETE"
REST-URI-Fragment = people/{userId}/activities/{activityId}
(5) Get an Activity
REST-HTTP-Method = "GET"
REST-URI-Fragment = /people/{userId}/activities/{activityId}
(6) Get Activities for given activity IDs with optional filters
(7) Get Activities for given user IDs with optional filters
*AppData Related Operations:*
(1) Get AppData
REST-HTTP-Method = "GET"
REST-URI-Fragment = /people/{userId}/appdata/{appId}
(2) Create AppData
REST-HTTP-Method = "POST"
REST-URI-Fragment = /people/{userId}/appdata/{appId}
(3) Update AppData
REST-HTTP-Method = "PUT"
REST-URI-Fragment = /people/{userId}/appdata/{appId}
(4) Delete AppData
REST-HTTP-Method = "DELETE"
REST-URI-Fragment = /people/{userId}/appdata/{appId}
Thanks,
~Umashanthi
>
>>
>> [0] https://cwiki.apache.org/PHOTARKxWIKI/photark-rest-api.html
>> [1]
>> http://opensocial-resources.googlecode.com/svn/spec/1.1/Social-API-Server.xml#People-Service
>>
>>
>> Thanks,
>> ~Umashanthi
>>
>>
>> On Sat, Jul 9, 2011 at 9:47 PM, Umashanthi Pavalanathan <
>> umashanthip@gmail.com> wrote:
>>
>>>
>>>
>>> On Sat, Jul 9, 2011 at 9:42 PM, Luciano Resende <lu...@gmail.com>wrote:
>>>
>>>> On Fri, Jul 8, 2011 at 3:58 AM, Umashanthi Pavalanathan
>>>> <um...@gmail.com> wrote:
>>>> > Hi Devs,
>>>> >
>>>> > As you know I am working on adding social features to PhotArk in the
>>>> rest
>>>> > branch.
>>>> > To proceed further with the implementation, I have to add the social
>>>> > features in the UI. When working on this, I came across the
>>>> requirement of
>>>> > exposing the back-end functionalities as REST services. As you know,
>>>> > implementation in the trunk uses Apache Tuscany to integrate and
>>>> expose the
>>>> > functionality as JSON-RPC. Similarly in the rest branch we have the
>>>> > requirement of exposing the back-end functionality as REST services.
>>>> For
>>>> > this purpose, I looked into three options:
>>>> > (1) Apache Shindig [0]
>>>> > (2) Apache Tuscany [1]
>>>> > (3) Apache Wookie [2]
>>>> >
>>>> > As we have discussed earlier in the mailing list [3], Apache Shindig
>>>> > provides a reference implementation for the OpenSocial specification
>>>> and
>>>> > provide JSON-RPC & REST APIs. But these APIs are only limited to the
>>>> > concepts/services in the OpenSocial specification and currently there
>>>> seems
>>>> > to be no plans for extending further. So, using Apache Shindig, we can
>>>> > integrate the back-end social features as REST services; but it is
>>>> only
>>>> > limited to this purpose. Since in the context of PhotArk, there are
>>>> several
>>>> > other functionalities/concepts like Albums, etc, using Shindig will
>>>> not
>>>> > cater for all the requirements.
>>>> >
>>>> > On the other hand, Apache Tuscany, can be used to expose the
>>>> functionalities
>>>> > as REST services without any limitations and it's usage in the PhotArk
>>>> trunk
>>>> > assures that it can satisfy all the requirements in PhotArk.
>>>> >
>>>> > Apaceh Wookie also provides REST API. But it is particularly designed
>>>> to
>>>> > facilitate building widgets. Similar to Shindig, Wookie also has
>>>> limited
>>>> > support for converting all the functionalities in PhotArk into REST
>>>> > services. Even though Wookie has the support for UI widgets, I do not
>>>> see
>>>> > any plans to make PhotArk as a widget based application in the near
>>>> future.
>>>> > So the REST integration facility provided by Wookie is limited in the
>>>> > context of PhotArk.
>>>> >
>>>> > After analyzing these three options, Apache Tuscany seems to be
>>>> promising
>>>> > for me, to support all the requirements of PhotArk, related to
>>>> exposing REST
>>>> > services.
>>>> >
>>>> > I kindly invite you all to proceed further with this discussion. Your
>>>> > valuable input to this discussion is highly appreciated.
>>>> >
>>>> > Looking forward to hear from you all.
>>>> >
>>>> >
>>>> > [0] http://shindig.apache.org/
>>>> > [1] http://tuscany.apache.org/
>>>> > [2] http://incubator.apache.org/wookie/
>>>> > [3]
>>>> >
>>>> http://www.mail-archive.com/photark-dev@incubator.apache.org/msg01141.html
>>>> >
>>>> > Thanks,
>>>> > ~Umashanthi
>>>> >
>>>>
>>>> I had the impression that the integration with Apache Shindig would
>>>> provide us much more benefits, but after some investigation I don't
>>>> believe that is true anymore. A REST interface based on Tuscany should
>>>> give us enough to build a solid social ui. Having said that, we might
>>>> look at the URI defined by Shindig/OpenSocial to see if we can follow
>>>> the same standard which would be beneficial for any future
>>>> integration.
>>>>
>>>
>>> +1.
>>> Since Tuscany has the flexibility in defining the URI (please correct me
>>> if I am wrong), I think we can incorporate the OpenSocial URI standards for
>>> our services.
>>>
>>>
>>> Thanks,
>>> ~Umashanthi
>>>
>>>
>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Luciano Resende
>>>> http://people.apache.org/~lresende
>>>> http://twitter.com/lresende1975
>>>> http://lresende.blogspot.com/
>>>>
>>>
>>>
>>
>
Re: REST integration for back-end functionality in photark-rest branch
Posted by Umashanthi Pavalanathan <um...@gmail.com>.
On Mon, Jul 11, 2011 at 9:56 AM, Umashanthi Pavalanathan <
umashanthip@gmail.com> wrote:
> Hi Devs,
>
> I have come up with the REST URI scheme for the Person and relationship
> related Social concepts.
> I used the PhotArk REST API [0] and the OpenSocial REST API [1] as
> references for this purpose.
>
> The following are my initial thoughts. You feedback & suggestions are
> welcomed.
>
> (1) Get a Person
>
> REST-HTTP-Method = "GET"
>
> REST-URI-Fragment = /people/{userId}/@self
>
>
> (2) Get a Person's friends
>
> REST-HTTP-Method = "GET"
> REST-URI-Fragment = /people/{userId}/@friends
>
>
> (3) Get all Persons
>
> REST-HTTP-Method = "GET"
> REST-URI-Fragment = /people
>
>
> (4) Update a Person
>
> REST-HTTP-Method = "POST"
> REST-URI-Fragment = /people/{userId}
>
>
correction:
Update a Person
REST-HTTP-Method = "PUT"
REST-URI-Fragment = /people/{userId}
> (5) Delete a person
>
> REST-HTTP-Method = "DELETE"
> REST-URI-Fragment = /people/{userId}
>
>
> (6) Create a Relationship request
>
> REST-HTTP-Method = "POST"
> REST-URI-Fragment = "/people/realtionship/{ownerId}/{viewerId}
>
>
> (7) Create a Relationship
>
> REST-HTTP-Method = "POST"
> REST-URI-Fragment = "/people/relationship/{ownerId}/{viewerId}
>
>
> (8) Get Relationship between two users
>
> REST-HTTP-Method = "GET"
> REST-URI-Fragment = "/people/relationship/{ownerId}/{viewerId}
>
>
> (9) Remove Relationship between two users
>
> REST-HTTP-Method = "DELETE"
> REST-URI-Fragment = "/people/realtionship/{ownerId}/{viewerId}
>
>
>
> [0] https://cwiki.apache.org/PHOTARKxWIKI/photark-rest-api.html
> [1]
> http://opensocial-resources.googlecode.com/svn/spec/1.1/Social-API-Server.xml#People-Service
>
>
> Thanks,
> ~Umashanthi
>
>
> On Sat, Jul 9, 2011 at 9:47 PM, Umashanthi Pavalanathan <
> umashanthip@gmail.com> wrote:
>
>>
>>
>> On Sat, Jul 9, 2011 at 9:42 PM, Luciano Resende <lu...@gmail.com>wrote:
>>
>>> On Fri, Jul 8, 2011 at 3:58 AM, Umashanthi Pavalanathan
>>> <um...@gmail.com> wrote:
>>> > Hi Devs,
>>> >
>>> > As you know I am working on adding social features to PhotArk in the
>>> rest
>>> > branch.
>>> > To proceed further with the implementation, I have to add the social
>>> > features in the UI. When working on this, I came across the requirement
>>> of
>>> > exposing the back-end functionalities as REST services. As you know,
>>> > implementation in the trunk uses Apache Tuscany to integrate and expose
>>> the
>>> > functionality as JSON-RPC. Similarly in the rest branch we have the
>>> > requirement of exposing the back-end functionality as REST services.
>>> For
>>> > this purpose, I looked into three options:
>>> > (1) Apache Shindig [0]
>>> > (2) Apache Tuscany [1]
>>> > (3) Apache Wookie [2]
>>> >
>>> > As we have discussed earlier in the mailing list [3], Apache Shindig
>>> > provides a reference implementation for the OpenSocial specification
>>> and
>>> > provide JSON-RPC & REST APIs. But these APIs are only limited to the
>>> > concepts/services in the OpenSocial specification and currently there
>>> seems
>>> > to be no plans for extending further. So, using Apache Shindig, we can
>>> > integrate the back-end social features as REST services; but it is only
>>> > limited to this purpose. Since in the context of PhotArk, there are
>>> several
>>> > other functionalities/concepts like Albums, etc, using Shindig will not
>>> > cater for all the requirements.
>>> >
>>> > On the other hand, Apache Tuscany, can be used to expose the
>>> functionalities
>>> > as REST services without any limitations and it's usage in the PhotArk
>>> trunk
>>> > assures that it can satisfy all the requirements in PhotArk.
>>> >
>>> > Apaceh Wookie also provides REST API. But it is particularly designed
>>> to
>>> > facilitate building widgets. Similar to Shindig, Wookie also has
>>> limited
>>> > support for converting all the functionalities in PhotArk into REST
>>> > services. Even though Wookie has the support for UI widgets, I do not
>>> see
>>> > any plans to make PhotArk as a widget based application in the near
>>> future.
>>> > So the REST integration facility provided by Wookie is limited in the
>>> > context of PhotArk.
>>> >
>>> > After analyzing these three options, Apache Tuscany seems to be
>>> promising
>>> > for me, to support all the requirements of PhotArk, related to exposing
>>> REST
>>> > services.
>>> >
>>> > I kindly invite you all to proceed further with this discussion. Your
>>> > valuable input to this discussion is highly appreciated.
>>> >
>>> > Looking forward to hear from you all.
>>> >
>>> >
>>> > [0] http://shindig.apache.org/
>>> > [1] http://tuscany.apache.org/
>>> > [2] http://incubator.apache.org/wookie/
>>> > [3]
>>> >
>>> http://www.mail-archive.com/photark-dev@incubator.apache.org/msg01141.html
>>> >
>>> > Thanks,
>>> > ~Umashanthi
>>> >
>>>
>>> I had the impression that the integration with Apache Shindig would
>>> provide us much more benefits, but after some investigation I don't
>>> believe that is true anymore. A REST interface based on Tuscany should
>>> give us enough to build a solid social ui. Having said that, we might
>>> look at the URI defined by Shindig/OpenSocial to see if we can follow
>>> the same standard which would be beneficial for any future
>>> integration.
>>>
>>
>> +1.
>> Since Tuscany has the flexibility in defining the URI (please correct me
>> if I am wrong), I think we can incorporate the OpenSocial URI standards for
>> our services.
>>
>>
>> Thanks,
>> ~Umashanthi
>>
>>
>>
>>>
>>>
>>> --
>>>
>>> Luciano Resende
>>> http://people.apache.org/~lresende
>>> http://twitter.com/lresende1975
>>> http://lresende.blogspot.com/
>>>
>>
>>
>
Re: REST integration for back-end functionality in photark-rest branch
Posted by Umashanthi Pavalanathan <um...@gmail.com>.
Hi Devs,
I have come up with the REST URI scheme for the Person and relationship
related Social concepts.
I used the PhotArk REST API [0] and the OpenSocial REST API [1] as
references for this purpose.
The following are my initial thoughts. You feedback & suggestions are
welcomed.
(1) Get a Person
REST-HTTP-Method = "GET"
REST-URI-Fragment = /people/{userId}/@self
(2) Get a Person's friends
REST-HTTP-Method = "GET"
REST-URI-Fragment = /people/{userId}/@friends
(3) Get all Persons
REST-HTTP-Method = "GET"
REST-URI-Fragment = /people
(4) Update a Person
REST-HTTP-Method = "POST"
REST-URI-Fragment = /people/{userId}
(5) Delete a person
REST-HTTP-Method = "DELETE"
REST-URI-Fragment = /people/{userId}
(6) Create a Relationship request
REST-HTTP-Method = "POST"
REST-URI-Fragment = "/people/realtionship/{ownerId}/{viewerId}
(7) Create a Relationship
REST-HTTP-Method = "POST"
REST-URI-Fragment = "/people/relationship/{ownerId}/{viewerId}
(8) Get Relationship between two users
REST-HTTP-Method = "GET"
REST-URI-Fragment = "/people/relationship/{ownerId}/{viewerId}
(9) Remove Relationship between two users
REST-HTTP-Method = "DELETE"
REST-URI-Fragment = "/people/realtionship/{ownerId}/{viewerId}
[0] https://cwiki.apache.org/PHOTARKxWIKI/photark-rest-api.html
[1]
http://opensocial-resources.googlecode.com/svn/spec/1.1/Social-API-Server.xml#People-Service
Thanks,
~Umashanthi
On Sat, Jul 9, 2011 at 9:47 PM, Umashanthi Pavalanathan <
umashanthip@gmail.com> wrote:
>
>
> On Sat, Jul 9, 2011 at 9:42 PM, Luciano Resende <lu...@gmail.com>wrote:
>
>> On Fri, Jul 8, 2011 at 3:58 AM, Umashanthi Pavalanathan
>> <um...@gmail.com> wrote:
>> > Hi Devs,
>> >
>> > As you know I am working on adding social features to PhotArk in the
>> rest
>> > branch.
>> > To proceed further with the implementation, I have to add the social
>> > features in the UI. When working on this, I came across the requirement
>> of
>> > exposing the back-end functionalities as REST services. As you know,
>> > implementation in the trunk uses Apache Tuscany to integrate and expose
>> the
>> > functionality as JSON-RPC. Similarly in the rest branch we have the
>> > requirement of exposing the back-end functionality as REST services. For
>> > this purpose, I looked into three options:
>> > (1) Apache Shindig [0]
>> > (2) Apache Tuscany [1]
>> > (3) Apache Wookie [2]
>> >
>> > As we have discussed earlier in the mailing list [3], Apache Shindig
>> > provides a reference implementation for the OpenSocial specification and
>> > provide JSON-RPC & REST APIs. But these APIs are only limited to the
>> > concepts/services in the OpenSocial specification and currently there
>> seems
>> > to be no plans for extending further. So, using Apache Shindig, we can
>> > integrate the back-end social features as REST services; but it is only
>> > limited to this purpose. Since in the context of PhotArk, there are
>> several
>> > other functionalities/concepts like Albums, etc, using Shindig will not
>> > cater for all the requirements.
>> >
>> > On the other hand, Apache Tuscany, can be used to expose the
>> functionalities
>> > as REST services without any limitations and it's usage in the PhotArk
>> trunk
>> > assures that it can satisfy all the requirements in PhotArk.
>> >
>> > Apaceh Wookie also provides REST API. But it is particularly designed to
>> > facilitate building widgets. Similar to Shindig, Wookie also has limited
>> > support for converting all the functionalities in PhotArk into REST
>> > services. Even though Wookie has the support for UI widgets, I do not
>> see
>> > any plans to make PhotArk as a widget based application in the near
>> future.
>> > So the REST integration facility provided by Wookie is limited in the
>> > context of PhotArk.
>> >
>> > After analyzing these three options, Apache Tuscany seems to be
>> promising
>> > for me, to support all the requirements of PhotArk, related to exposing
>> REST
>> > services.
>> >
>> > I kindly invite you all to proceed further with this discussion. Your
>> > valuable input to this discussion is highly appreciated.
>> >
>> > Looking forward to hear from you all.
>> >
>> >
>> > [0] http://shindig.apache.org/
>> > [1] http://tuscany.apache.org/
>> > [2] http://incubator.apache.org/wookie/
>> > [3]
>> >
>> http://www.mail-archive.com/photark-dev@incubator.apache.org/msg01141.html
>> >
>> > Thanks,
>> > ~Umashanthi
>> >
>>
>> I had the impression that the integration with Apache Shindig would
>> provide us much more benefits, but after some investigation I don't
>> believe that is true anymore. A REST interface based on Tuscany should
>> give us enough to build a solid social ui. Having said that, we might
>> look at the URI defined by Shindig/OpenSocial to see if we can follow
>> the same standard which would be beneficial for any future
>> integration.
>>
>
> +1.
> Since Tuscany has the flexibility in defining the URI (please correct me if
> I am wrong), I think we can incorporate the OpenSocial URI standards for our
> services.
>
>
> Thanks,
> ~Umashanthi
>
>
>
>>
>>
>> --
>>
>> Luciano Resende
>> http://people.apache.org/~lresende
>> http://twitter.com/lresende1975
>> http://lresende.blogspot.com/
>>
>
>
Re: REST integration for back-end functionality in photark-rest branch
Posted by Umashanthi Pavalanathan <um...@gmail.com>.
On Sat, Jul 9, 2011 at 9:42 PM, Luciano Resende <lu...@gmail.com>wrote:
> On Fri, Jul 8, 2011 at 3:58 AM, Umashanthi Pavalanathan
> <um...@gmail.com> wrote:
> > Hi Devs,
> >
> > As you know I am working on adding social features to PhotArk in the rest
> > branch.
> > To proceed further with the implementation, I have to add the social
> > features in the UI. When working on this, I came across the requirement
> of
> > exposing the back-end functionalities as REST services. As you know,
> > implementation in the trunk uses Apache Tuscany to integrate and expose
> the
> > functionality as JSON-RPC. Similarly in the rest branch we have the
> > requirement of exposing the back-end functionality as REST services. For
> > this purpose, I looked into three options:
> > (1) Apache Shindig [0]
> > (2) Apache Tuscany [1]
> > (3) Apache Wookie [2]
> >
> > As we have discussed earlier in the mailing list [3], Apache Shindig
> > provides a reference implementation for the OpenSocial specification and
> > provide JSON-RPC & REST APIs. But these APIs are only limited to the
> > concepts/services in the OpenSocial specification and currently there
> seems
> > to be no plans for extending further. So, using Apache Shindig, we can
> > integrate the back-end social features as REST services; but it is only
> > limited to this purpose. Since in the context of PhotArk, there are
> several
> > other functionalities/concepts like Albums, etc, using Shindig will not
> > cater for all the requirements.
> >
> > On the other hand, Apache Tuscany, can be used to expose the
> functionalities
> > as REST services without any limitations and it's usage in the PhotArk
> trunk
> > assures that it can satisfy all the requirements in PhotArk.
> >
> > Apaceh Wookie also provides REST API. But it is particularly designed to
> > facilitate building widgets. Similar to Shindig, Wookie also has limited
> > support for converting all the functionalities in PhotArk into REST
> > services. Even though Wookie has the support for UI widgets, I do not see
> > any plans to make PhotArk as a widget based application in the near
> future.
> > So the REST integration facility provided by Wookie is limited in the
> > context of PhotArk.
> >
> > After analyzing these three options, Apache Tuscany seems to be promising
> > for me, to support all the requirements of PhotArk, related to exposing
> REST
> > services.
> >
> > I kindly invite you all to proceed further with this discussion. Your
> > valuable input to this discussion is highly appreciated.
> >
> > Looking forward to hear from you all.
> >
> >
> > [0] http://shindig.apache.org/
> > [1] http://tuscany.apache.org/
> > [2] http://incubator.apache.org/wookie/
> > [3]
> >
> http://www.mail-archive.com/photark-dev@incubator.apache.org/msg01141.html
> >
> > Thanks,
> > ~Umashanthi
> >
>
> I had the impression that the integration with Apache Shindig would
> provide us much more benefits, but after some investigation I don't
> believe that is true anymore. A REST interface based on Tuscany should
> give us enough to build a solid social ui. Having said that, we might
> look at the URI defined by Shindig/OpenSocial to see if we can follow
> the same standard which would be beneficial for any future
> integration.
>
+1.
Since Tuscany has the flexibility in defining the URI (please correct me if
I am wrong), I think we can incorporate the OpenSocial URI standards for our
services.
Thanks,
~Umashanthi
>
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>
Re: REST integration for back-end functionality in photark-rest branch
Posted by Luciano Resende <lu...@gmail.com>.
On Fri, Jul 8, 2011 at 3:58 AM, Umashanthi Pavalanathan
<um...@gmail.com> wrote:
> Hi Devs,
>
> As you know I am working on adding social features to PhotArk in the rest
> branch.
> To proceed further with the implementation, I have to add the social
> features in the UI. When working on this, I came across the requirement of
> exposing the back-end functionalities as REST services. As you know,
> implementation in the trunk uses Apache Tuscany to integrate and expose the
> functionality as JSON-RPC. Similarly in the rest branch we have the
> requirement of exposing the back-end functionality as REST services. For
> this purpose, I looked into three options:
> (1) Apache Shindig [0]
> (2) Apache Tuscany [1]
> (3) Apache Wookie [2]
>
> As we have discussed earlier in the mailing list [3], Apache Shindig
> provides a reference implementation for the OpenSocial specification and
> provide JSON-RPC & REST APIs. But these APIs are only limited to the
> concepts/services in the OpenSocial specification and currently there seems
> to be no plans for extending further. So, using Apache Shindig, we can
> integrate the back-end social features as REST services; but it is only
> limited to this purpose. Since in the context of PhotArk, there are several
> other functionalities/concepts like Albums, etc, using Shindig will not
> cater for all the requirements.
>
> On the other hand, Apache Tuscany, can be used to expose the functionalities
> as REST services without any limitations and it's usage in the PhotArk trunk
> assures that it can satisfy all the requirements in PhotArk.
>
> Apaceh Wookie also provides REST API. But it is particularly designed to
> facilitate building widgets. Similar to Shindig, Wookie also has limited
> support for converting all the functionalities in PhotArk into REST
> services. Even though Wookie has the support for UI widgets, I do not see
> any plans to make PhotArk as a widget based application in the near future.
> So the REST integration facility provided by Wookie is limited in the
> context of PhotArk.
>
> After analyzing these three options, Apache Tuscany seems to be promising
> for me, to support all the requirements of PhotArk, related to exposing REST
> services.
>
> I kindly invite you all to proceed further with this discussion. Your
> valuable input to this discussion is highly appreciated.
>
> Looking forward to hear from you all.
>
>
> [0] http://shindig.apache.org/
> [1] http://tuscany.apache.org/
> [2] http://incubator.apache.org/wookie/
> [3]
> http://www.mail-archive.com/photark-dev@incubator.apache.org/msg01141.html
>
> Thanks,
> ~Umashanthi
>
I had the impression that the integration with Apache Shindig would
provide us much more benefits, but after some investigation I don't
believe that is true anymore. A REST interface based on Tuscany should
give us enough to build a solid social ui. Having said that, we might
look at the URI defined by Shindig/OpenSocial to see if we can follow
the same standard which would be beneficial for any future
integration.
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/