On Friday, April 11, 2014, Tyson Norris <[email protected]> wrote: > > > > On Apr 10, 2014, at 11:26 PM, "Ian Boston" <[email protected] <javascript:;>> > 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?
What would happen if the servlet was mounted at /api/v1/foo ? I think /bar would appear in path info, as iirc the resource resolver finds the first existing resource. Have you tried that? Ian > > 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 <[email protected]<javascript:;>> > 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 > >> <[email protected]<javascript:;> > <javascript:;> > >> <mailto:[email protected] <javascript:;> <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 > >> <[email protected]<javascript:;> > <javascript:;> > >> <mailto:[email protected] <javascript:;> <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 > >> > >> > >> > >> >
