Hi Roy, Yes my reference to data/content was based on the OP stating he'll be storing data in JCR, so effectively yes he probably could just use a JCR repo backend.
I'm not totally discounting Sling as an API platform, just that it probably won't integrate easily with other API frameworks (e.g. JAX-RS, Spring, etc.). Also if the API is serving more than JCR "resources" (i.e. some form of data processing) then it will probably need to use servlets. A lot of maybes I guess. ;-) regards, ben On 29 January 2017 at 09:32, Roy Teeuwen <r...@teeuwen.be> wrote: > Hey Ben, > > I have to argue you on that one though. The short definition of Apache > Sling from the main site, definitely look at point 1: > > Apache Sling in five bullets points > > • REST based web framework > • Content-driven, using a JCR content repository > • Powered by OSGi > • Scripting inside, multiple languages (JSP, server-side > javascript, Scala, etc.) > • Apache Open Source project > > Talking about sling as only data/content is just addressing the JCR / > Apache OAK part of Sling, then you can just as well say, drop sling and > just use oak to store the data/content > > Greets > Roy > > > On 28 Jan 2017, at 23:27, Ben Fortuna <benfort...@gmail.com> wrote: > > > > Hi Henry, > > > > I agree with what you say about keeping it simple and using a servlet. > > However there are many frameworks and platforms today geared towards > making > > it easier to implement REST APIs, and I think non-trivial APIs would > > probably benefit from using one. > > > > As such, to me an API should live outside the Sling process and use sling > > as a data/content source. > > > > Regards, > > Ben > > > > On 29 Jan 2017 6:09 AM, "Henry Saginor" <hsaginor.apa...@gmail.com> > 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. > >>> > >>> Theoretically I assume that your resource could provide an ACL as the > >>> ACL is just a resource in the tree. > >> I am not sure if you can do this since ACLs are at JCR level and are > >> checked via JCR. > >>> > >>> As others suggested using a resource provider in this way may not be > the > >>> best solution. As the whole point of Sling is to manage content and > >>> splitting it into different pieces can be awkward. > >>> > >>> I'm assuming that you don't need to do POST operations, and that using > >>> Oak with an S3 file storage configuration is out. > >>> > >>> If you can tell Sling what's on the remote store, you could just use a > >>> reference to the data. In the same way that in AEM, an image component > >>> doesn't necessarily have the image, rather it can have a pointer to the > >>> image. So your renderer can just go out and retrieve the image and > >>> return it. > >>> > >>> Or, the Sling Resource Merger > >>> https://sling.apache.org/documentation/bundles/resource-merger.html > >>> > >>> In this case you can merge your resource provider with a JCR Path. So > >>> that your resource provider provides the remote content while the > >>> associated meta data can be stored in the JCR. Haven't tried this > myself > >>> though. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> -- > >>> Jason > >>> > >>> On Fri, Jan 27, 2017, at 04:27 PM, lancedolan wrote: > >>>> Hi friends, > >>>> > >>>> I've tried routing questions through stackoverflow to cut down my > mails > >>>> to > >>>> this list. I'm losing lots of time on this one, though, and am stuck. > >>>> > >>>> I need to create APIs which don't represent Sling Resources. Example: > >>>> /services/images/123123123 > >>>> that image will exist somewhere else. > >>>> > >>>> Bertrand suggests creating a ResourceProvider, as in the example here > >>>> [1]. > >>>> However, that uses the spi package which is not in version 2.9.0 of > >>>> org.apache.sling.api, and thus, not available to me in Sling 8. > >>>> > >>>> I did find a ResourceProvider interface to implement though, and > created > >>>> this code: > >>>> > >>>> /** > >>>> * Created by lancedolan on 1/27/17. > >>>> */ > >>>> @Component > >>>> @Service(value=ResourceProvider.class) > >>>> @Properties({ > >>>> @Property(name = ResourceProvider.ROOTS, value = "things"), > >>>> @Property(name = ResourceProvider.OWNS_ROOTS, value = "true") > >>>> }) > >>>> public class ImageResourceProvider implements ResourceProvider { > >>>> > >>>> /** If this provider required a context this would be more > elaborate, > >>>> * but for this simple example we don't need one. > >>>> */ > >>>> public static class DoesNotNeedAContext { > >>>> }; > >>>> > >>>> @Override > >>>> public Resource getResource(ResourceResolver resourceResolver, > String > >>>> path) { > >>>> Resource returnResource = new SyntheticResource( > >> resourceResolver, > >>>> path, "edlio/microservice/image"); > >>>> returnResource.getValueMap().put("myProp" , "myValue"); > >>>> return returnResource; > >>>> } > >>>> > >>>> @Override > >>>> public Resource getResource(ResourceResolver resourceResolver, > >>>> HttpServletRequest httpServletRequest, String path) { > >>>> return getResource(resourceResolver , path); > >>>> } > >>>> > >>>> @Override > >>>> public Iterator<Resource> listChildren(Resource resource) { > >>>> return null; > >>>> } > >>>> } > >>>> > >>>> > >>>> The result is that I get a 403 response. How do I control the > >>>> authentication > >>>> for resources that don't actually exist? The fact that I'm not getting > >>>> 404 > >>>> means that my ResourceProvider is at least registering successfully. > >>>> > >>>> Finally, I'd much prefer to use Jersey if possible... Anybody have > >>>> success > >>>> getting Jersey to work in Sling 8? I dumped a bunch of time into it > and > >>>> gave > >>>> up after class not found errors for classes that should be found [2]. > >>>> > >>>> The ultimate goal is just to provide a restful API in Sling 8 and the > >>>> static-path-declaration of SlingSafeMethodsServlet just doesn't cut > it. > >>>> > >>>> Thanks a million guys... > >>>> > >> > >> > >
