Hi Lance,

I would personally recommend that you find a different solution for serving
REST APIs. I also thought it might be good to service an API from Sling, as
it does make JSON a "first class citizen", but then I realised that Sling
is geared towards serving resources from JCR and ultimately you'll be
fighting with the platform to serve an API without all the JCR metadata.

At very least you could try to run Jersey using plain Servlets, but I think
Sling should be left to do what it is meant for.

Other solutions such as Spring Boot or Ratpack are specifically designed
for serving REST APIs, and with Docker it is trivial to support both a
Sling platform for web content and an API back-end on the same server.

One thing about REST APIs I do think Sling is good for is stubbing. You can
easily create example API responses to test your web UI without needing to
run with a back-end (good for UI testing).

regards,
ben


On 28 January 2017 at 08:27, lancedolan <lance.do...@gmail.com> 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...
>
>
>
> [1]
> https://github.com/apache/sling/blob/trunk/launchpad/
> test-services/src/main/java/org/apache/sling/launchpad/
> testservices/resourceprovider/PlanetsResourceProvider.java
>
> [2] http://stackoverflow.com/questions/41901337/how-to-use-jersey-in-sling
>
>
>
>
>
> --
> View this message in context: http://apache-sling.73963.n3.
> nabble.com/How-to-create-Rest-APIs-for-non-JCR-data-in-
> Sling-8-tp4069947.html
> Sent from the Sling - Users mailing list archive at Nabble.com.
>

Reply via email to