10 p.m.
The initial draft of the REST API specification is available now
https://community.jboss.org/wiki/GateInRESTAPISpecification. I tried to
design it as RESTful as possible for now, and we can decide if some
complexity that comes with REST is appropriate for the GateIn REST API.
For example Twitter's REST API is fairly easy to understand, however
some would not call it quite so "RESTful".
Also this specification conflicts with the stuff I've built for GateIn
Management, especially the organization of the resources (pages,
navigation, etc). However we should be in sync with how the Public Java
API is going to expose these resources. For example if I can do
api.getPages() as apposed to api.getSite().getPages() then Pages should
be a "first class resource".
All feedback is welcome.
- Nick
10:38 p.m.
Hi Nick,
here are my initial comments remarks
1/ for pagination I see "page=2&per-page=10" can it work in a reliable
manner with concurrency ? (i.e if I go on page 2 and someone added a result meanwhile).
2/ at some point there will a few improvements in application management, in particular we
should have the capability to scope applications per site (like pages and navigations).
The current proposal to use
/applications/app-type/app-id
will be an issue as it will not be possible to scope an application to a site.
And the existing application registry should be seen as a "parent" registry.
3/ for site based API : why do we have the scheme /something/site-type/site-name/foobar
and not /sites/site-type/site-name/concern/foobar ?
this would enable to have /applications per site (see remark 2) and have a global
/applications for current application registry without conflicts.
4/ the current model for application registry is broken and prevents to do a correct API
(java or rest). I want to change that for the next major version, you should be prepared
to this change.
Basically an application is seen in the application registry as en entry of
/production/app:applications/category/application but the corresponding configuration
application is a node under /production/mop:workspace/mop:customizations/application
For instance
"/production/mop:workspace/mop:customizations/mop:Todo"
and
"/production/app:applications/app:Gadgets/app:Todo"
This is broken because an application can be described twice with different data, i.e
there can be several entries under app:applications/* that can point to the same
customization (the real application).
Worse than that the same application can appear twice in the application registry with
different security permissions.
I want to fix this and instead remove the application part of the app:applications.
Instead use mixins to put on a customization to add the data that will describe it (i.e
enhance it) with the mixins gtn:described and gtn:protectedresource we have already in
gatein.
The app:applications would somehow remain but it would be a simple relationship to the
customization itself instead of en entity. This would allow the same application to appear
in several categories. There would be a new mixin to make an application point to several
categories to put on an application. This would provide the many-to-many relationship
between application and categories.
That's the only major changes I foresee so far in MOP for the next major version.
On Mar 30, 2012, at 10:00 PM, Nick Scavelli wrote:
The initial draft of the REST API specification is available now
https://community.jboss.org/wiki/GateInRESTAPISpecification. I tried to design it as
RESTful as possible for now, and we can decide if some complexity that comes with REST is
appropriate for the GateIn REST API. For example Twitter's REST API is fairly easy to
understand, however some would not call it quite so "RESTful".
Also this specification conflicts with the stuff I've built for GateIn Management,
especially the organization of the resources (pages, navigation, etc). However we should
be in sync with how the Public Java API is going to expose these resources. For example if
I can do api.getPages() as apposed to api.getSite().getPages() then Pages should be a
"first class resource".
All feedback is welcome.
- Nick
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
11:05 p.m.
for more clarity I started a spec about MOP 2.0 :
https://community.jboss.org/wiki/ModelObjectForPortal20
On Mar 30, 2012, at 10:38 PM, Julien Viet wrote:
Hi Nick,
here are my initial comments remarks
1/ for pagination I see "page=2&per-page=10" can it work in a reliable
manner with concurrency ? (i.e if I go on page 2 and someone added a result meanwhile).
2/ at some point there will a few improvements in application management, in particular
we should have the capability to scope applications per site (like pages and navigations).
The current proposal to use
/applications/app-type/app-id
will be an issue as it will not be possible to scope an application to a site.
And the existing application registry should be seen as a "parent" registry.
3/ for site based API : why do we have the scheme /something/site-type/site-name/foobar
and not /sites/site-type/site-name/concern/foobar ?
this would enable to have /applications per site (see remark 2) and have a global
/applications for current application registry without conflicts.
4/ the current model for application registry is broken and prevents to do a correct API
(java or rest). I want to change that for the next major version, you should be prepared
to this change.
Basically an application is seen in the application registry as en entry of
/production/app:applications/category/application but the corresponding configuration
application is a node under /production/mop:workspace/mop:customizations/application
For instance
"/production/mop:workspace/mop:customizations/mop:Todo"
and
"/production/app:applications/app:Gadgets/app:Todo"
This is broken because an application can be described twice with different data, i.e
there can be several entries under app:applications/* that can point to the same
customization (the real application).
Worse than that the same application can appear twice in the application registry with
different security permissions.
I want to fix this and instead remove the application part of the app:applications.
Instead use mixins to put on a customization to add the data that will describe it (i.e
enhance it) with the mixins gtn:described and gtn:protectedresource we have already in
gatein.
The app:applications would somehow remain but it would be a simple relationship to the
customization itself instead of en entity. This would allow the same application to appear
in several categories. There would be a new mixin to make an application point to several
categories to put on an application. This would provide the many-to-many relationship
between application and categories.
That's the only major changes I foresee so far in MOP for the next major version.
On Mar 30, 2012, at 10:00 PM, Nick Scavelli wrote:
> The initial draft of the REST API specification is available now
https://community.jboss.org/wiki/GateInRESTAPISpecification. I tried to design it as
RESTful as possible for now, and we can decide if some complexity that comes with REST is
appropriate for the GateIn REST API. For example Twitter's REST API is fairly easy to
understand, however some would not call it quite so "RESTful".
>
> Also this specification conflicts with the stuff I've built for GateIn
Management, especially the organization of the resources (pages, navigation, etc). However
we should be in sync with how the Public Java API is going to expose these resources.
For example if I can do api.getPages() as apposed to api.getSite().getPages() then Pages
should be a "first class resource".
>
> All feedback is welcome.
>
> - Nick
> _______________________________________________
> gatein-dev mailing list
> gatein-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/gatein-dev
6:30 p.m.
For pagination, I think that it will be useful to add some parameters to
control sorting. Kind of sorting (asc, desc) and maybe also column for
sorting, so for instance you can choose to sort pages by pageName or
ownerId etc.
Marek
On 30.3.2012 22:38, Julien Viet wrote:
Hi Nick,
here are my initial comments remarks
1/ for pagination I see "page=2&per-page=10" can it work in a
reliable manner with concurrency ? (i.e if I go on page 2 and someone
added a result meanwhile).
2/ at some point there will a few improvements in application
management, in particular we should have the capability to scope
applications per site (like pages and navigations). The current
proposal to use
/applications/app-type/app-id
will be an issue as it will not be possible to scope an application to
a site.
And the existing application registry should be seen as a "parent"
registry.
3/ for site based API : why do we have the scheme
/something/site-type/site-name/foobar and not
/sites/site-type/site-name/concern/foobar ?
this would enable to have /applications per site (see remark 2) and
have a global /applications for current application registry without
conflicts.
4/ the current model for application registry is broken and prevents
to do a correct API (java or rest). I want to change that for the next
major version, you should be prepared to this change.
Basically an application is seen in the application registry as en
entry of /production/app:applications/category/application but the
corresponding configuration application is a node under
/production/mop:workspace/mop:customizations/application
For instance
"/production/mop:workspace/mop:customizations/mop:Todo"
and
"/production/app:applications/app:Gadgets/app:Todo"
This is broken because an application can be described twice with
different data, i.e there can be several entries under
app:applications/* that can point to the same customization (the real
application).
Worse than that the same application can appear twice in the
application registry with different security permissions.
I want to fix this and instead remove the application part of the
app:applications.
Instead use mixins to put on a customization to add the data that will
describe it (i.e enhance it) with the mixins gtn:described and
gtn:protectedresource we have already in gatein.
The app:applications would somehow remain but it would be a simple
relationship to the customization itself instead of en entity. This
would allow the same application to appear in several
categories. There would be a new mixin to make an application point to
several categories to put on an application. This would provide the
many-to-many relationship between application and categories.
That's the only major changes I foresee so far in MOP for the next
major version.
On Mar 30, 2012, at 10:00 PM, Nick Scavelli wrote:
> The initial draft of the REST API specification is available now
> https://community.jboss.org/wiki/GateInRESTAPISpecification. I tried
> to design it as RESTful as possible for now, and we can decide if
> some complexity that comes with REST is appropriate for the GateIn
> REST API. For example Twitter's REST API is fairly easy to
> understand, however some would not call it quite so "RESTful".
>
> Also this specification conflicts with the stuff I've built for
> GateIn Management, especially the organization of the resources
> (pages, navigation, etc). However we should be in sync with how the
> Public Java API is going to expose these resources. For example if I
> can do api.getPages() as apposed to api.getSite().getPages() then
> Pages should be a "first class resource".
>
> All feedback is welcome.
>
> - Nick
> _______________________________________________
> gatein-dev mailing list
> gatein-dev(a)lists.jboss.org <mailto:gatein-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/gatein-dev
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
8:10 p.m.
On 03/30/2012 04:38 PM, Julien Viet wrote:
Hi Nick,
here are my initial comments remarks
1/ for pagination I see "page=2&per-page=10" can it work in a
reliable manner with concurrency ? (i.e if I go on page 2 and someone
added a result meanwhile).
No it cannot unless we keep state on the server. See my
discussion point
on this, where we can pass a token back to the client which could expire
if the collection has changed. Atom spec just says that results are
lossy, see http://tools.ietf.org/html/rfc5005#section-3. We may just go
with this approach for first iteration.
2/ at some point there will a few improvements in application
management, in particular we should have the capability to scope
applications per site (like pages and navigations). The current
proposal to use
/applications/app-type/app-id
will be an issue as it will not be possible to scope an application to
a site.
So we will have applications that are "global" and some that are
specific to a site ? I'll have to think about this.
And the existing application registry should be seen as a "parent"
registry.
Do you mean instead of /registry/applications it should just be
/appregistry ?
3/ for site based API : why do we have the scheme
/something/site-type/site-name/foobar and not
/sites/site-type/site-name/concern/foobar ?
this would enable to have /applications per site (see remark 2) and
have a global /applications for current application registry without
conflicts.
This is how I organized the resources for gatein management and
something I am interested in hearing from others. I think it makes sense
to represent it this way and /pages, etc are more just search views that
eventually link to /sites/site-type/site-name/concern/foobar.
So for example /pages = [
{
"site-type": "portal"
"site-name": "classic"
"page-name": "homepage"
"link": {
"href" : "/sites/portal/classic/homepage"
"rel" : "gtn:page"
}
},
...
]
4/ the current model for application registry is broken and prevents
to do a correct API (java or rest). I want to change that for the next
major version, you should be prepared to this change.
We should be able to design
the API on how we see this looking right ?
In other words the API can be the use case on making the underlying
model and implementation better.
Basically an application is seen in the application registry as en
entry of /production/app:applications/category/application but the
corresponding configuration application is a node under
/production/mop:workspace/mop:customizations/application
For instance
"/production/mop:workspace/mop:customizations/mop:Todo"
and
"/production/app:applications/app:Gadgets/app:Todo"
This is broken because an application can be described twice with
different data, i.e there can be several entries under
app:applications/* that can point to the same customization (the real
application).
Worse than that the same application can appear twice in the
application registry with different security permissions.
I want to fix this and instead remove the application part of the
app:applications.
Instead use mixins to put on a customization to add the data that will
describe it (i.e enhance it) with the mixins gtn:described and
gtn:protectedresource we have already in gatein.
The whole customization's
thing for the MOP is confusing. Can we not
make a generic application that has portlet and gadget mixins and drop
the whole customization thing ? I am not too familiar with this and not
sure if this even makes sense.
The app:applications would somehow remain but it would be a simple
relationship to the customization itself instead of en entity. This
would allow the same application to appear in several
categories. There would be a new mixin to make an application point to
several categories to put on an application. This would provide the
many-to-many relationship between application and categories.
That's the only major changes I foresee so far in MOP for the next
major version.
On Mar 30, 2012, at 10:00 PM, Nick Scavelli wrote:
> The initial draft of the REST API specification is available now
> https://community.jboss.org/wiki/GateInRESTAPISpecification. I tried
> to design it as RESTful as possible for now, and we can decide if
> some complexity that comes with REST is appropriate for the GateIn
> REST API. For example Twitter's REST API is fairly easy to
> understand, however some would not call it quite so "RESTful".
>
> Also this specification conflicts with the stuff I've built for
> GateIn Management, especially the organization of the resources
> (pages, navigation, etc). However we should be in sync with how the
> Public Java API is going to expose these resources. For example if I
> can do api.getPages() as apposed to api.getSite().getPages() then
> Pages should be a "first class resource".
>
> All feedback is welcome.
>
> - Nick
> _______________________________________________
> gatein-dev mailing list
> gatein-dev(a)lists.jboss.org <mailto:gatein-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/gatein-dev
5:26 p.m.
On 03/30/2012 04:38 PM, Julien Viet wrote:
<snip>
3/ for site based API : why do we have the scheme
/something/site-type/site-name/foobar and not
/sites/site-type/site-name/concern/foobar ?
I think the reason is to be able to list all pages independent of site,
however I'm not sure how strong the use case is for this. So since
applications can be global and possibly unique to a site I think there
are two (possibly three ways) of supporting this.
** 1 **
The application resource becomes the following:
/applications/global/{app-type}/{app-id} - for global applications
/applications/{portal|group|user}/{site-name}/{app-type}/{app-id} -
for site specific applications.
Navigation and pages resource stay the same.
Solution 2: (which is basically how the mop is layed out and how the MOP
extension lays out the resources for gatein-management over REST)
Page resource becomes:
/sites/{site-type}/{site-name}/pages/{page-name}
Navigation resource becomes:
/sites/{site-type}/{site-name}/navigation/{node-id}
Application resource becomes:
/applications/{app-type}/{app-id} - for global applications
/sites/{site-type}/{site-name}/applications/{app-type}/{app-id} -
for site specific applications
** 3 **
Same layout as number 2 but we support /pages and /navigation as well
and the results link to the /sites resource. For example:
/pages = [
{
"name": "homepage",
"link": {
"href": "/sites/portal/classic/pages/homepage"
"rel": "gtn:page"
}
},
...
]
4394
days inactive
4418
days old
5 comments
3 participants
participants (3)
-
Julien Viet -
Marek Posolda -
Nick Scavelli