Re: [gatein-dev] REST API Specification

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