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...@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
