+1 for cachable requests with the Vary-header! Regards Julian
On Mon, Apr 7, 2014 at 4:52 PM, Robert Munteanu <rob...@lmn.ro> wrote: > 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
