Another idea was proposed to generally solve access to OSGI objects (configs
and services).
1. OSGI configs need to be managed (CRUD) over HTTP and access should be
controlled at factory and config level.
URL hierarchy:
- /system/osgiconfigs/factoryPid/{configFriendlyName}
- configFriendlyName will be provided in a OSGI config property
sling:friendlyName
ACLs are controlled via representative JCR nodes:
- root node /system/osgiconfigs - controls access to the whole hierarchy
- intermediate nodes are optional, a node like /system/osgiconfigs/factoryPid
controls access to managing configs of a certain factory
- implementation will be done using a ModifyingResourceProvider and access will
be secured with a ResourceAccessGate
Questions:
- should we expose all configs or only selected ones (for example those that
have the property sling:friendlyName)?
- should we use a ResourceProvider per factory in order to customize the
provider better. The following customization options are useful:
---- define a custom root for config factory (for example
/etc/replication/config)
---- define exactly what properties are exposed from configs belonging to a
factory by using a whitelist
2. OSGI services need to be exposed over HTTP in order to make it easy to link
them to servlets that execute actions on them.
URL hierarchy:
- /system/osgiservices/servicePid
- services should have a property to (sling:resourceType or different) that
will be used as the resource type of the associated resources
- servlets can use the designated resource type to bind and execute methods on
the associated services.
ACLs are controlled via respresentative JCR nodes
- root node /system/osgiservices is mandatory and controls access to whole
hierarchy
- sub nodes are optional and allow fine grained control at service level
- implementation will be done using a ResourceProvider and access will be
secured with a ResourceAccessGate
Questions:
- should we expose all services or just the ones having the designated property?
- should we use a ResourceProvider per service interface so that we can
customize it better?
---- define a custom root node for a service interface (for example
/system/replication/agent for ReplicationAgents)
This is just the initial proposal. Feedback will be greatly valued on the
general approach, but also on the particular questions of whether a single
hierarchy for all objects is desirable or a more granular strategy should be
taken. Related to that, should we expose all objects by default or just those
that have certain properties?
Marius
> -----Original Message-----
> From: Carsten Ziegeler [mailto:[email protected]]
> Sent: Tuesday, February 18, 2014 11:15 AM
> To: [email protected]
> Subject: Re: Replication REST-ful/HTTP API
>
> I prefer the granular design as well - and just to reiterate, the Sling
> concepts for
> this are resource providers (and resource access security)
>
> Regards
> Carsten
>
>
> 2014-02-18 9:47 GMT+01:00 Tommaso Teofili <[email protected]>:
>
> > Does anyone else have any opinion and / or concerns? It'd be nice if
> > we can move forward.
> >
> > Regards,
> > Tommaso
> >
> >
> > 2014-02-14 2:29 GMT+01:00 Alexander Klimetschek <[email protected]>:
> >
> > > On 13.02.2014, at 13:44, Tommaso Teofili <[email protected]>
> > > wrote:
> > >
> > > > I personally prefer the granular one as it's more resource
> > > > oriented,
> > > which
> > > > makes more sense in my opinion for an HTTP API (be it REST or not)
> > >
> > > Regarding REST: It is closer to REST only once you send out links to
> > > the various options/commands.
> > >
> > > If the client needs to build the request itself and has to know URL
> > > patterns or other headers or payload paths, it misses the hypermedia
> > > constraint.
> > >
> > > So in itself, there is no real difference between granular and
> > > flatten in the proposal:
> > >
> > > POST /system/replication/agent/{agentName}/replicate
> > >
> > > and
> > >
> > > POST /system/replication/all/replicate { "agents" : [ "publish1",
> > > "publish2" ] // ....
> > > }
> > >
> > > However, the granular one has the advantage that you can more easily
> > > do the linking, for example using standard <form> and hrefs.
> > >
> > > Basically, if you can browse it with some simple HTML pages and do
> > > everything (find all agents, look at agent state, clear queue,
> > > import package etc.), then this is good.
> > >
> > > Just my 2 cents
> > > Alex
> >
>
>
>
> --
> Carsten Ziegeler
> [email protected]
