So in my naïve response to your situation. I don’t see the problem with mapping
directly to the resource model, the first thing I would do is to import the
information into the node tree structure. The exact structure isn’t really
important as long as it mirrors the intent of the request.
/content/document1
/content/document2
/content/document2/true/version1
/content/document2/true/version2
Then for each level where a file should be returned uses a sling
sling:resourceType that returns the file.
If you have restrictions, like you know the name of the file but the versions
of the file are maintained separately and you don't have an ability to import.
You can have a node structure like
/content/{document}/true
With the sling:resourceType for the document retrieving the document in
question and the resourceType for true locating the version that's being
requested.
If you don't know the document ahead of time, then you're back to a very
generic servlet interacting with another system. I would still avoid the
universal solution and look to implement something very specific for these
types of requests, based an identifier for the service.
-Jason
From: Duy Nguyen
Sent: Friday, March 6, 2015 12:14 PM
To: [email protected]
Hi,
Sorry for the formatting error, as there were 3 different urls actually:
/myhost/{documentName}
/myhost//{hasRevision}/{revisionID}
/myhost/-/users/{userName}
* So in your example, it is like:
/host/whitepaper
/host/whitepaper/true/version-1
/host/-/users/john123
(I avoid .pdf as it can be misleading to a selector which is not the
idea of my question)
---
Duy
On Fri, Mar 6, 2015, at 15:15, Jason E Bailey wrote:
So I can get a clear picture of the request, a typical request would be
for?
/host/whitepaper.pdf/host/true/version-1/host/-/users/john123
--=20
Jason
On Fri, Mar 6, 2015, at 09:50 AM, Duy Nguyen wrote:
> Hello,
>=20
> I'm bringing here a use case in Sling and look forward to receiving some
> opinions from the community.
>=20
> I need to write a server-side app that serves customized RESTful APIs for
> a
> client app (which is stable and the set of APIs is fixed). The problem
> comes from "ugly" API urls that can hardly be mapped into the resource
> model of Sling, for example:
>=20
> */myhost/{documentName}/myhost/{**documentName*
> *}/{hasRevision}/{revisionID}/myhost/-/users/{userName}*
>=20
> Especially properties like =E2=80=9CdocumentName", =E2=80=9CrevisionID" a=
nd "userName"
> are
> not necessarily stored in jcr resources, but can also be from external
> sources. The flag =E2=80=9ChasRevision=E2=80=9D is either true or false v=
alue, to check
> if
> the document has revision to be returned. So there must be some
> middleware
> that handles the requests coming to each of those paths (to determine if
> the needed resource can be retrieved from jcr or external sources, and
> revision to be taken into account).
>=20
> Thinking in the implementation of some regular web frameworks (Django,
> Sinatra, etc.), it can be done by route mapping, such as:
> *get("/myhost/:**documentName*
> */:hasRevision?/:revisionID?") function()
> {=E2=80=A6}get("/myhost/-/users/:userName") function() {=E2=80=A6}*
>=20
> Initially I have come up with two solutions in Sling:
>=20
> 1- Write a "global SlingServlet" for "/myhost/", and then the rest of the
> url are params that will be analyzed in the servlet to handle different
> request patterns. However I don't think this is a very elegant solution,
> because this only one servlet is responsible for all requests following
> the
> path.
>=20
> 2- Use Sling Resource Mappings
> <http://sling.apache.org/documentation/the-sling-engine/mappings-for-reso=
urce-resolution.html>
> to
> redirect the requests (categorized by reg-ex) to different resources, and
> then write separate SlingServlet for each of those resources. I still
> have
> some doubt if this is feasible.
>=20
> Do you have some suggestions?
>=20
> Thanks,
> Duy
