Hi,
This style of REST is supported. There are 2 options, probably more,
assuming that you have written your Api implementing using servlets. Mount
the servlets at a hard coded path using the sling servlet annotation, but
this won't allow you to acl the end point, or give the Api a resource type,
and create some nodes to mount it at the desired path. Don't think of the
path as content, think of it as a mount point form your Api. The advantage
of the latter is it becomes easy to remount and acl.
You can also mount jaxrs as a osgi servlet, but the processing model of
implementations like RESTEasy is incompatible with sling. If you do that,
you are on your own as far as the resource resolver.
Best regards
Ian
Sent from my ipad, sorry for the typos.
On Thursday, April 10, 2014, Tyson Norris <tnor...@adobe.com> wrote:
> along the lines of supporting REST-ful APIs, is there any way (mapping?
> etc) to support an api like :
> GET /api/v1/foo/bar
>
> where:
> - /api and /v1 are obviously not content paths
> - foo and bar are not sling resources, but might be treated as synthetic
> resources if that is required
> - we cannot use Accept header (is it possible to use .json as a default
> extension?)
>
> we are in the process of defining some apis that exist alongside other
> platforms that use apis in this common url format, and it would be really
> nice to use something like jaxrs style tokens for paths that are not sling
> resource, but yet desired to be exposed as urls (I know, this is not the
> way of sling in general...) e.g. @Path("/users/{username}")
>
> Side note: I haven't looks into the sling jaxrs support added via
> https://issues.apache.org/jira/browse/SLING-2192, but plan to try it out
> - does it support path tokens/wildcards?
>
> Thanks for any ideas.
> Tyson
>
>
> On Apr 7, 2014, at 5:33 PM, Alexander Klimetschek
> <aklim...@adobet.com<javascript:;>
> <mailto:aklim...@adobe.com <javascript:;>>> wrote:
>
> Proposal sounds good to me. I would agree to move this to a plugin that
> gets the accept header (is there anything else?) and can update any
> existing selectors/extension/suffix (the PathInfo) parsed already.
>
> void updatePathInfo(String[] accepts, PathInfo pathInfo);
>
> Notes:
> - accept header already parsed (might need to be a special object to
> include weights)
> - PathInfo is basically a RequestPathInfo with setters
>
> While the default would not do anything if something was taken from the
> URL, this might still be useful once you support accept headers this way,
> and applications could extend that behaviour. Or simply turn it off (as it
> is now).
>
> Cheers,
> Alex
>
>
> On 07.04.2014, at 13:39, Julian Reschke <julian.resc...@gmx.de<javascript:;>
> <mailto:julian.resc...@gmx.de <javascript:;>>> wrote:
>
> On 2014-04-07 15:59, Felix Meschberger wrote:
> Hi
>
> Ok, it is not exactly arbitrary logic. Turns out that content types of the
> style
>
> application/someformat+somesyntax
>
> are pretty common (see [1], [2]). Also when talking about REST-ful APIs I
> expect some application on the other (client) side and this will in general
> not come with a list of content types but with a single one asking for a
> concrete representation.
> ...
>
> The "structured syntax" is defined in <http://tools.ietf.org/html/rfc6839>
> -- note that you can't simply make up these suffixes (nor media types...).
>
> Best regards, Julian
>
>
>
>
