You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Felix Meschberger <fm...@adobe.com> on 2014/02/12 11:55:39 UTC
Replication REST-ful/HTTP API
Hi
There are at least two Sling issues currently discussing REST-ful (or HTTP) API approaches for the new replication module: SLING-3385 [1] and SLING-3352 [2].,
Instead of independently find and discuss solutions, I would prefer to see a complete picture proposal for such APIs. How about you, @Marius, creating some proposal on the Sling Wiki (as a child to [3]) that we can further discuss and then implement ?
Thanks
Felix
[1] https://issues.apache.org/jira/browse/SLING-3385
[2] https://issues.apache.org/jira/browse/SLING-3352
[3] https://cwiki.apache.org/confluence/display/SLING/Concepts+and+Ideas
Re: Replication REST-ful/HTTP API
Posted by Julian Sedding <js...@gmail.com>.
Hi Marius
Thanks for the patch. However, I think you misunderstood my
suggestion. The idea was that there is a well-defined property (e.g.
sling:osgiConfigPid), which can be set on a JCR node, this points to
the configuration that should be "mounted" on this node.
I'll try to illustrate it with an example:
/etc/replication/agents/author (JCR node):
{
"jcr:primaryType": "nt:unstructured", // could optionally use
some marker node-type
"sling:osgiConfigPid":
"org.apache.sling.replication.agent.impl.ReplicationAgentServiceFactory-author",
"sling:resourceType": "replication/agent" // entirely optional,
but may be useful to provide different renderings for different
configs
}
Then your ResourceProvider could have its root set e.g. to "/etc" and
thus be given a chance to handle any requests for resources in that
tree. It would look at the underlying JCR node's sling:osgiConfigPid
property, and if present enrich it with service/config specific
additional properties (may be useful for rendering), or maybe even
child-resources (I haven't thought the details of the mapping
through).
Using such an approach would enforce that config resources are indeed
backed by a JCR node (and can thus be restricted with ACLs), it also
allows greater flexibility in placing the configuration UIs at
arbitrary paths.
Does that make sense?
Regards
Julian
On Mon, Feb 24, 2014 at 2:42 PM, Marius Petria <mp...@adobe.com> wrote:
> Hi,
>
> I have provided an initial implementation in a patch for [1]. It allows to customize the resource provider so that downstream users can choose which property should be used as the friendly name (as Julian suggested). We can add also a customization option to specify a resource type.
>
> Basically a resource provider for OSGI configs can be configured as follows:
> {
> "name" : "replicationAgents",
> "provider.roots" : [ "/etc/replication/config/agents" ],
> "friendlyNameProperty" : "name",
> "configFactoryPid" : "org.apache.sling.replication.agent.impl.ReplicationAgentServiceFactory"
> }
>
> Marius
>
> [1] https://issues.apache.org/jira/browse/SLING-3352
>
>
>
>
>> -----Original Message-----
>> From: Julian Sedding [mailto:jsedding@gmail.com]
>> Sent: Friday, February 21, 2014 12:51 PM
>> To: dev@sling.apache.org
>> Subject: Re: Replication REST-ful/HTTP API
>>
>> Hi Marius
>>
>> I like the general direction of your proposal. The only concern I have is that you
>> require properties on the services (sling:friendlyName and maybe
>> sling:resourceType). Since this requires modification of the service
>> implementation this cannot flexibly be used by downstream users of this
>> feature.
>>
>> However, if you require some JCR node structure as a skeleton for the hierarchy
>> in any case, why don't you just reference the service/service-factory from a
>> property on the respective nodes? This would allow:
>>
>> * fine or coarse grained access control as required,
>> * flexible placement/naming of the hierarchy (e.g. it would be possible to map
>> replication services into /etc/replication and other sevrices to /system/...)
>>
>> Regards
>> Julian
>>
>>
>>
>>
>>
>> On Thu, Feb 20, 2014 at 1:12 PM, Tommaso Teofili
>> <to...@gmail.com> wrote:
>> > Hi Marius,
>> >
>> > 2014-02-20 9:58 GMT+01:00 Marius Petria <mp...@adobe.com>:
>> >
>> >> 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
>> >>
>> >>
>> > looks good to me, especially because this is a generic solution that
>> > can be leveraged for other use cases.
>> >
>> >
>> >> Questions:
>> >> - should we expose all configs or only selected ones (for example
>> >> those that have the property sling:friendlyName)?
>> >>
>> >
>> > being this a generic proposal affecting all the existing configs,
>> > maybe it'd be better to not expose anything by default.
>> >
>> >
>> >> - should we use a ResourceProvider per factory in order to customize
>> >> the provider better.
>> >
>> >
>> > maybe it'd be good to have a generic one that works on a config
>> > factory resourcetype and then that could be overridden by a custom one
>> > in case it's needed.
>> >
>> >
>> >> 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
>> >>
>> >>
>> > looks good to me, I'm not sure about the property to be used for the
>> > resourcetype, however that's just a detail.
>> >
>> >
>> >> 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)
>> >>
>> >>
>> > probably same as above, no service exposed by default.
>> >
>> >
>> >>
>> >> 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?
>> >>
>> >
>> > I'd expose only resources (either for configs or services) that are
>> > configured on purpose to be exposed (having certain properties), using
>> > a granular approach.
>> >
>> > Regards,
>> > Tommaso
>> >
>> >
>> >>
>> >> Marius
>> >>
>> >> > -----Original Message-----
>> >> > From: Carsten Ziegeler [mailto:cziegeler@apache.org]
>> >> > Sent: Tuesday, February 18, 2014 11:15 AM
>> >> > To: dev@sling.apache.org
>> >> > 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
>> <to...@gmail.com>:
>> >> >
>> >> > > 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
>> <ak...@adobe.com>:
>> >> > >
>> >> > > > On 13.02.2014, at 13:44, Tommaso Teofili
>> >> > > > <to...@gmail.com>
>> >> > > > 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
>> >> > cziegeler@apache.org
>> >>
RE: Replication REST-ful/HTTP API
Posted by Marius Petria <mp...@adobe.com>.
Hi,
I have provided an initial implementation in a patch for [1]. It allows to customize the resource provider so that downstream users can choose which property should be used as the friendly name (as Julian suggested). We can add also a customization option to specify a resource type.
Basically a resource provider for OSGI configs can be configured as follows:
{
"name" : "replicationAgents",
"provider.roots" : [ "/etc/replication/config/agents" ],
"friendlyNameProperty" : "name",
"configFactoryPid" : "org.apache.sling.replication.agent.impl.ReplicationAgentServiceFactory"
}
Marius
[1] https://issues.apache.org/jira/browse/SLING-3352
> -----Original Message-----
> From: Julian Sedding [mailto:jsedding@gmail.com]
> Sent: Friday, February 21, 2014 12:51 PM
> To: dev@sling.apache.org
> Subject: Re: Replication REST-ful/HTTP API
>
> Hi Marius
>
> I like the general direction of your proposal. The only concern I have is that you
> require properties on the services (sling:friendlyName and maybe
> sling:resourceType). Since this requires modification of the service
> implementation this cannot flexibly be used by downstream users of this
> feature.
>
> However, if you require some JCR node structure as a skeleton for the hierarchy
> in any case, why don't you just reference the service/service-factory from a
> property on the respective nodes? This would allow:
>
> * fine or coarse grained access control as required,
> * flexible placement/naming of the hierarchy (e.g. it would be possible to map
> replication services into /etc/replication and other sevrices to /system/...)
>
> Regards
> Julian
>
>
>
>
>
> On Thu, Feb 20, 2014 at 1:12 PM, Tommaso Teofili
> <to...@gmail.com> wrote:
> > Hi Marius,
> >
> > 2014-02-20 9:58 GMT+01:00 Marius Petria <mp...@adobe.com>:
> >
> >> 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
> >>
> >>
> > looks good to me, especially because this is a generic solution that
> > can be leveraged for other use cases.
> >
> >
> >> Questions:
> >> - should we expose all configs or only selected ones (for example
> >> those that have the property sling:friendlyName)?
> >>
> >
> > being this a generic proposal affecting all the existing configs,
> > maybe it'd be better to not expose anything by default.
> >
> >
> >> - should we use a ResourceProvider per factory in order to customize
> >> the provider better.
> >
> >
> > maybe it'd be good to have a generic one that works on a config
> > factory resourcetype and then that could be overridden by a custom one
> > in case it's needed.
> >
> >
> >> 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
> >>
> >>
> > looks good to me, I'm not sure about the property to be used for the
> > resourcetype, however that's just a detail.
> >
> >
> >> 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)
> >>
> >>
> > probably same as above, no service exposed by default.
> >
> >
> >>
> >> 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?
> >>
> >
> > I'd expose only resources (either for configs or services) that are
> > configured on purpose to be exposed (having certain properties), using
> > a granular approach.
> >
> > Regards,
> > Tommaso
> >
> >
> >>
> >> Marius
> >>
> >> > -----Original Message-----
> >> > From: Carsten Ziegeler [mailto:cziegeler@apache.org]
> >> > Sent: Tuesday, February 18, 2014 11:15 AM
> >> > To: dev@sling.apache.org
> >> > 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
> <to...@gmail.com>:
> >> >
> >> > > 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
> <ak...@adobe.com>:
> >> > >
> >> > > > On 13.02.2014, at 13:44, Tommaso Teofili
> >> > > > <to...@gmail.com>
> >> > > > 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
> >> > cziegeler@apache.org
> >>
Re: Replication REST-ful/HTTP API
Posted by Julian Sedding <js...@gmail.com>.
Hi Marius
I like the general direction of your proposal. The only concern I have
is that you require properties on the services (sling:friendlyName and
maybe sling:resourceType). Since this requires modification of the
service implementation this cannot flexibly be used by downstream
users of this feature.
However, if you require some JCR node structure as a skeleton for the
hierarchy in any case, why don't you just reference the
service/service-factory from a property on the respective nodes? This
would allow:
* fine or coarse grained access control as required,
* flexible placement/naming of the hierarchy (e.g. it would be
possible to map replication services into /etc/replication and other
sevrices to /system/...)
Regards
Julian
On Thu, Feb 20, 2014 at 1:12 PM, Tommaso Teofili
<to...@gmail.com> wrote:
> Hi Marius,
>
> 2014-02-20 9:58 GMT+01:00 Marius Petria <mp...@adobe.com>:
>
>> 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
>>
>>
> looks good to me, especially because this is a generic solution that can be
> leveraged for other use cases.
>
>
>> Questions:
>> - should we expose all configs or only selected ones (for example those
>> that have the property sling:friendlyName)?
>>
>
> being this a generic proposal affecting all the existing configs, maybe
> it'd be better to not expose anything by default.
>
>
>> - should we use a ResourceProvider per factory in order to customize the
>> provider better.
>
>
> maybe it'd be good to have a generic one that works on a config factory
> resourcetype and then that could be overridden by a custom one in case it's
> needed.
>
>
>> 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
>>
>>
> looks good to me, I'm not sure about the property to be used for the
> resourcetype, however that's just a detail.
>
>
>> 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)
>>
>>
> probably same as above, no service exposed by default.
>
>
>>
>> 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?
>>
>
> I'd expose only resources (either for configs or services) that are
> configured on purpose to be exposed (having certain properties), using a
> granular approach.
>
> Regards,
> Tommaso
>
>
>>
>> Marius
>>
>> > -----Original Message-----
>> > From: Carsten Ziegeler [mailto:cziegeler@apache.org]
>> > Sent: Tuesday, February 18, 2014 11:15 AM
>> > To: dev@sling.apache.org
>> > 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 <to...@gmail.com>:
>> >
>> > > 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 <ak...@adobe.com>:
>> > >
>> > > > On 13.02.2014, at 13:44, Tommaso Teofili <to...@gmail.com>
>> > > > 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
>> > cziegeler@apache.org
>>
Re: Replication REST-ful/HTTP API
Posted by Tommaso Teofili <to...@gmail.com>.
Hi Marius,
2014-02-20 9:58 GMT+01:00 Marius Petria <mp...@adobe.com>:
> 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
>
>
looks good to me, especially because this is a generic solution that can be
leveraged for other use cases.
> Questions:
> - should we expose all configs or only selected ones (for example those
> that have the property sling:friendlyName)?
>
being this a generic proposal affecting all the existing configs, maybe
it'd be better to not expose anything by default.
> - should we use a ResourceProvider per factory in order to customize the
> provider better.
maybe it'd be good to have a generic one that works on a config factory
resourcetype and then that could be overridden by a custom one in case it's
needed.
> 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
>
>
looks good to me, I'm not sure about the property to be used for the
resourcetype, however that's just a detail.
> 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)
>
>
probably same as above, no service exposed by default.
>
> 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?
>
I'd expose only resources (either for configs or services) that are
configured on purpose to be exposed (having certain properties), using a
granular approach.
Regards,
Tommaso
>
> Marius
>
> > -----Original Message-----
> > From: Carsten Ziegeler [mailto:cziegeler@apache.org]
> > Sent: Tuesday, February 18, 2014 11:15 AM
> > To: dev@sling.apache.org
> > 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 <to...@gmail.com>:
> >
> > > 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 <ak...@adobe.com>:
> > >
> > > > On 13.02.2014, at 13:44, Tommaso Teofili <to...@gmail.com>
> > > > 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
> > cziegeler@apache.org
>
RE: Replication REST-ful/HTTP API
Posted by Marius Petria <mp...@adobe.com>.
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:cziegeler@apache.org]
> Sent: Tuesday, February 18, 2014 11:15 AM
> To: dev@sling.apache.org
> 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 <to...@gmail.com>:
>
> > 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 <ak...@adobe.com>:
> >
> > > On 13.02.2014, at 13:44, Tommaso Teofili <to...@gmail.com>
> > > 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
> cziegeler@apache.org
Re: Replication REST-ful/HTTP API
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <to...@gmail.com>:
> 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 <ak...@adobe.com>:
>
> > On 13.02.2014, at 13:44, Tommaso Teofili <to...@gmail.com>
> > 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
cziegeler@apache.org
Re: Replication REST-ful/HTTP API
Posted by Tommaso Teofili <to...@gmail.com>.
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 <ak...@adobe.com>:
> On 13.02.2014, at 13:44, Tommaso Teofili <to...@gmail.com>
> 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
Re: Replication REST-ful/HTTP API
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 13.02.2014, at 13:44, Tommaso Teofili <to...@gmail.com> 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
Re: Replication REST-ful/HTTP API
Posted by Tommaso Teofili <to...@gmail.com>.
Thanks Marius for the detailed proposal.
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) and that
was in fact the rationale that drove the current design.
Also the flatten design looks ok, however having to make two API calls to
get the status of a certain replication doesn't sound too nice to me.
However I would go for either the granular one or the flatten one, not a
mixture of them.
Regards,
Tommaso
2014-02-13 15:12 GMT+01:00 Marius Petria <mp...@adobe.com>:
> Hi,
>
> I have placed the proposal to [1].
>
> Thanks,
> Marius
>
> [1]
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=38572805
>
>
> > -----Original Message-----
> > From: Marius Petria [mailto:mpetria@adobe.com]
> > Sent: Wednesday, February 12, 2014 4:59 PM
> > To: dev@sling.apache.org
> > Subject: RE: Replication REST-ful/HTTP API
> >
> > I will do that.
> >
> > Thanks,
> > Marius
> >
> > > -----Original Message-----
> > > From: Felix Meschberger [mailto:fmeschbe@adobe.com]
> > > Sent: Wednesday, February 12, 2014 12:56 PM
> > > To: dev@sling.apache.org
> > > Subject: Replication REST-ful/HTTP API
> > >
> > > Hi
> > >
> > > There are at least two Sling issues currently discussing REST-ful (or
> > > HTTP) API approaches for the new replication module: SLING-3385 [1]
> > > and SLING-3352 [2].,
> > >
> > > Instead of independently find and discuss solutions, I would prefer to
> > > see a complete picture proposal for such APIs. How about you, @Marius,
> > > creating some proposal on the Sling Wiki (as a child to [3]) that we
> > > can further discuss and then implement ?
> > >
> > > Thanks
> > > Felix
> > >
> > > [1] https://issues.apache.org/jira/browse/SLING-3385
> > > [2] https://issues.apache.org/jira/browse/SLING-3352
> > > [3]
> > > https://cwiki.apache.org/confluence/display/SLING/Concepts+and+Ideas
>
RE: Replication REST-ful/HTTP API
Posted by Marius Petria <mp...@adobe.com>.
Hi,
I have placed the proposal to [1].
Thanks,
Marius
[1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=38572805
> -----Original Message-----
> From: Marius Petria [mailto:mpetria@adobe.com]
> Sent: Wednesday, February 12, 2014 4:59 PM
> To: dev@sling.apache.org
> Subject: RE: Replication REST-ful/HTTP API
>
> I will do that.
>
> Thanks,
> Marius
>
> > -----Original Message-----
> > From: Felix Meschberger [mailto:fmeschbe@adobe.com]
> > Sent: Wednesday, February 12, 2014 12:56 PM
> > To: dev@sling.apache.org
> > Subject: Replication REST-ful/HTTP API
> >
> > Hi
> >
> > There are at least two Sling issues currently discussing REST-ful (or
> > HTTP) API approaches for the new replication module: SLING-3385 [1]
> > and SLING-3352 [2].,
> >
> > Instead of independently find and discuss solutions, I would prefer to
> > see a complete picture proposal for such APIs. How about you, @Marius,
> > creating some proposal on the Sling Wiki (as a child to [3]) that we
> > can further discuss and then implement ?
> >
> > Thanks
> > Felix
> >
> > [1] https://issues.apache.org/jira/browse/SLING-3385
> > [2] https://issues.apache.org/jira/browse/SLING-3352
> > [3]
> > https://cwiki.apache.org/confluence/display/SLING/Concepts+and+Ideas
RE: Replication REST-ful/HTTP API
Posted by Marius Petria <mp...@adobe.com>.
I will do that.
Thanks,
Marius
> -----Original Message-----
> From: Felix Meschberger [mailto:fmeschbe@adobe.com]
> Sent: Wednesday, February 12, 2014 12:56 PM
> To: dev@sling.apache.org
> Subject: Replication REST-ful/HTTP API
>
> Hi
>
> There are at least two Sling issues currently discussing REST-ful (or HTTP) API
> approaches for the new replication module: SLING-3385 [1] and SLING-3352
> [2].,
>
> Instead of independently find and discuss solutions, I would prefer to see a
> complete picture proposal for such APIs. How about you, @Marius, creating
> some proposal on the Sling Wiki (as a child to [3]) that we can further discuss
> and then implement ?
>
> Thanks
> Felix
>
> [1] https://issues.apache.org/jira/browse/SLING-3385
> [2] https://issues.apache.org/jira/browse/SLING-3352
> [3] https://cwiki.apache.org/confluence/display/SLING/Concepts+and+Ideas