[gatein-dev] REST API Specification

[Julien Viet]

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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/gatein-dev
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/gatein-dev/attachments/20120330/5ce61273/attachment.html