On Mon, Apr 7, 2014 at 5:50 PM, Marius Petria <mpet...@adobe.com> wrote: > Just a question on this. Isn't pushing the format information into headers > making caching more complicated?
It _should_ work if Sling adds the 'Vary: Accept' header. Robert > > 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 -- Sent from my (old) computer
