Re: conneg considered harmful

Question, what about Content-Location? Isn't this header specifically there
to inform the client / caches even if a negotiated representation was
returned, what the negotiated resource Uri is?


On Tue, May 21, 2013 at 9:12 PM, Glenn Block <[email protected]> wrote:

> Hello folks, been a long time!
>
> A very interesting and educational discussion indeed.
>
> Previously I have pushed quite heavily the support of server-driven
> conneg, which is something we enable quite easily in ASP.NET Web API
> though without redirects.
>
> It's possible to return a redirect, but that requires the user to do the
> heavy lifting.
>
> Can someone elaborate a bit more on the harms of not doing the redirect. I
> read through the different threads, but having a concise summary would be
> valuable.
>
> A different question this brings up is the concern of costs associated
> with doing this in particular for a cloud-hosted deployment where each
> request costs money / compute hours.
>
>
>    - Does adding in this redirect mean there's any significant cost
>    increase? If you are talking about secure or data that is dynamically
>    generated then a cache may not necessarily help offset that.
>    - Does the benefit outweight the cost in these cases?
>
> I am curious what folks on the list are doing with regards to APIs
> deployed in the cloud.
>
> Thanks!
> Glenn
>
>
>
>
>
>
> On Sat, Feb 16, 2013 at 2:01 AM, Alan Dean <[email protected]> wrote:
>
>> **
>>
>>
>> To be clear what Roy actually said was "In general, I avoid content
>> negotiation *without redirects* like the plague because of its effect on
>> caching." *(my emphasis)*
>>
>> Regards,
>> Alan Dean
>>
>>
>> On Sat, Feb 16, 2013 at 6:01 AM, Peter Williams <[email protected]>wrote:
>>
>>> Most of those don't talk about why using content negotiation is bad in
>>> general.  Instead they talk about how truly different resources should have
>>> their own uris even if they are variants of one another (eg articles about
>>> the same subject written in different human languages). That seems very
>>> reasonable.  However, those arguments don't apply to situations where
>>> multiple, truly mechanically translatable, representations of a single
>>> resource exist.
>>>
>>> One of those mention that conneg has a negative effect on caching. Is
>>> being harder to cache the only ill effect of sever driven conneg?
>>>
>>> Peter
>>> Barelyenough.org
>>> On Feb 15, 2013 3:31 PM, "Alan Dean" <[email protected]> wrote:
>>>
>>>> Perhaps it is worth referencing some other other Fielding quotes on the
>>>> subject:
>>>>
>>>> https://delicious.com/alan.dean/Roy.Fielding+conneg
>>>>
>>>> Regards,
>>>> Alan Dean
>>>>
>>>>
>>>> On Fri, Feb 15, 2013 at 8:21 PM, Peter Williams <[email protected]
>>>> > wrote:
>>>>
>>>>> **
>>>>>
>>>>>
>>>>> Eric,
>>>>>
>>>>> That is an interesting quote. I have occasionally heard
>>>>> unsubstantiated claims regarding the badness of accept header based
>>>>> content negotiation. It is interesting that Roy perceives it as
>>>>> "revolting".
>>>>>
>>>>> Personally, i rather like it but perhaps i am missing something
>>>>> important. I'd definitely like to hear someone (or multiple someones)
>>>>> actually articulate what they perceive as problematic about it. So far
>>>>> i don't recall ever reading a discussion of the downsides that got
>>>>> beyond "i don't like it" or "it is hard for me to implement" (neither
>>>>> of which resonate with me).
>>>>>
>>>>>
>>>>> On Wed, Feb 13, 2013 at 9:04 AM, Eric J. Bowman [email protected]>
>>>>> wrote:
>>>>> > Mark Baker wrote:
>>>>> >>
>>>>> >> Besides, client driven uses hypermedia so is way more RESTful.
>>>>>
>>>>> Mark, can you explain a bit more why you think this? It is not clear
>>>>> to me why avoiding this particular part of http's uniform interface
>>>>> would make a client more RESTful.
>>>>>
>>>>> Peter
>>>>> barelyenough.org
>>>>>
>>>>>
>>>>
>>  
>>
>
>