Just a question on this. Isn't pushing the format information into headers making caching more complicated?
Regards, Marius > -----Original Message----- > From: Carsten Ziegeler [mailto:cziege...@apache.org] > Sent: Monday, April 07, 2014 4:28 PM > To: dev@sling.apache.org > Subject: Re: Support REST-ful APIs > > I haven't thought in detail about this, but if we go such a way we should > think of improving the resolve() method of the resource resolver in some > way. > Today, when a request comes in, the full path is used to find the resource, > it's then shortened until an existing resource is found. If we have a request > which targets the resource and the accept header defines the > extension/selector, then there is no need for such an expensive search > mechanism anymore. > > Regards > Carsten > > > 2014-04-07 7:59 GMT-06:00 Felix Meschberger <fmesc...@adobe.com>: > > > 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. > > > > To have a plugin, you need to define and export an API and you have to > > take care about backwards compatibility and evolution. I don't exactly > > see where such a travel would lead to right now. > > > > As to other headers: This is about content type negotiation which > > involves as per the HTTP spec the Accept header. The Accept-Language > > header is for the language to be used for the representation of the > > resource but does not have an influence on the content type. > > > > Regards > > Felix > > > > [1] http://www.iana.org/assignments/media-types/media-types.xhtml > > [2] > > https://github.com/osgi/design/blob/master/rfcs/rfc0189/rfc-0189-Http_ > > Service_Updates.pdf?raw=true > > > > Am 07.04.2014 um 11:20 schrieb Julian Sedding <jsedd...@gmail.com>: > > > > > I agree with Bertrand. Generally, I'm in favor of supporting the > > > Accept > > header. > > > > > > However coding an arbitrary logic into Sling Engine (or some other > > > core bundle) does not sound good to me. > > > > > > The benefits of a pluggable solution would be > > > - preservation of modularity and > > > - the implementation of some "special" logic could live in a "contrib" > > > bundle, where it's easier to drop support, if the idea turns out to > > > be not so good. > > > - other headers, e.g. Accept-Language, could also be easily supported. > > > > > > Regards > > > Julian > > > > > > > > > On Mon, Apr 7, 2014 at 10:13 AM, Bertrand Delacretaz > > > <bdelacre...@apache.org> wrote: > > >> On Mon, Apr 7, 2014 at 9:58 AM, Felix Meschberger > > >> <fmesc...@adobe.com> > > wrote: > > >>> ...I would prefer to not go over board, at least not initially, > > >>> and > > keep it simple and covering simple use cases.... > > >> > > >> I like simple but what I object to is burning this into the Sling > > >> core > > >> - what you suggest is based on somewhat arbitrary rules (single > > >> content-type etc) which I don't feel good burning into the core. An > > >> extension point for setting selectors + extensions is not rocket > > >> science. > > >> > > >> -Bertrand > > > > > > > -- > Carsten Ziegeler > cziege...@apache.org
