> On Apr 10, 2014, at 11:26 PM, "Ian Boston" <i...@tfd.co.uk> wrote:
>
> 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.
>
I'm not sure how hard coding the paths allows for multiple urls can be served
on the same servlet using the path annotation (without using selectors etc)?
My example was misleading where:
/api/v1/foo/bar
Should be more like:
/api/v1/foo/{var}
Where {var} is some variable/id that does not easily map to a resource.
Which is why I wonder whether resource provider would be better suited to
handle this case than a servlet?
Thanks
Tyson
> 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
>>
>>
>>
>>
