Hi Tyson
Am 11.04.2014 um 00:35 schrieb Tyson Norris <tnor...@adobe.com>:
> along the lines of supporting REST-ful APIs, is there any way (mapping? etc)
> to support an api like :
> GET /api/v1/foo/bar
First and foremost: don't do the v1 thing since it is just wrong. An URL
addresses a resource and an address never contains a version. Using version
identifiers in so-called REST-ful HTTP APIs seems to be urban legend.
>
> 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?)
With my proposal you can (and should) use the Accept header instead of
extensions. In fact, my proposal supports extension-less Accept header based
support as well as browser-supported extensions without Accept header.
As for the mount point: I would think a ResourceProvider would do the trick.
You can root it at your API mount point and you can treat the path however you
like and map it to resources (regardless of whether they are virtual or real).
And you can even expose the template tokens as ResourceMetadata.
Regards
Felix
>
> 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...@adobe.com<mailto:aklim...@adobe.com>> 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<mailto:julian.resc...@gmx.de>> 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
>
>
>
