In general I agree with you, that's the simplest OP had a dual need. which is storing information about the asset in the JCR at the same time, which I don't see how your solution handles.
-- Jason On Sat, Jan 28, 2017, at 02:08 PM, Henry Saginor wrote: > In my opinion Sling is first and foremost a REST framework specifically > designed for this kind of thing. It’s not only to serve JCR content. > The paradigm Steven described earlier in this thread is EXACTLY the way > to implement it. In the Sling world the resource IS the RESTful object > addressable via a URI. The only thing I can add, as I wrote before, is > that it’s not necessary to implement a custom resource provider. > You can simply create JCR nodes/resources to map to your resource type > via sling:resourceType. And what your servlet returns is up to you and > your requirements. That works in most cases. > You can easily integrate your servlet with existing OSGi service via > declarative services and use any framework/library you need internally > (provided you can make it available in OSGi container) to integrate with > your data where it adds value. > But in my opinion it does not make sense integrating Sling with other > framework, such as Spring, which follow different paradigms to do the > same things as Sling + Declarative Services. It increases complexity and > does not add value. > > My advice is don’t shoot yourself in the foot and keep things as simple > as possible. Just implement a servlet, integrate with existing service > via DS if needed, and format and return the response based on your > requirements. Then create a resource (JCR or custom ResourceProvider), > map it to your servlet via sling:resourceType. This is how I have always > implemented RESTful services in Sling without many limitations. The > framework is specifically designed for this. > > Henry > > > On Jan 28, 2017, at 7:57 AM, Jason E Bailey <jason.bai...@24601.org> wrote: > > > > > > Its my understanding that the question on ACL's depends on where it is > > inheriting the ACL from. Taking your code as literal, you've declared > > that you own everything under /things and it would inherit the ACL of /. > > So if you put your ROOT as /content/remote/things You could set JCR ACLs > > on /content/remote.