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
