Re: content negotiation in BP doc

Hi again, Martynas,
Re the API/non-API distinction, yes, I agree that the distinction is 
blurry, but that just makes my point. If you post data through a REST 
API (as we hope people will), you should expect that some people will 
come there with a browser and try to look at the data that way. That is 
all the more reason to make it possible for people to be able to readily 
view multiple representations or share a link with the URI alone.

Unfortunately, there isn't a way to set the data format choices in the 
accept header through the browser. Yes, one can typically set a language 
preference, but we aren't talking about data appearing in different 
languages; we are talking about different file formats. Even if such a 
setting were available, I don't think that changing preferences 
constantly would be a reasonable thing to require of users as they 
browse your site. (The applications settings in Firefox set how the 
browser handles the content once it's received, which is too late for 
content negotiation.)

In my opinion, you need to expose the representations as resources in 
the case of publishing data. Otherwise, the alternative representations 
are not discoverable. But, again, there is still much argument about 
this. (Try googling around and you'll see what I mean, e.g. [1])

Re the CHIPS standard that you quoted, that guideline says to allow 
content managers to use content negotiation. It says nothing about when 
content managers should use it.

I'm happy to add the public list to this thread. (It started off-list BTW.)
-Annette

[1] 
http://programmers.stackexchange.com/questions/139654/rest-tradeoffs-between-content-negotiation-via-accept-header-versus-extensions

On 2/29/16 2:38 PM, Martynas Jusevičius wrote:
>  From the HTTP perspective, there's no API/non-API distinction. And
> browsers do let you configure acceptable media types and languages, to
> different extent. For example, in the latest Firefox, see
> about:preferences#applications and about:preferences#content >
> Languages.
>
> It comes down to the choice whether you only need to expose a resource
> with representations, or expose representations as resources as well.
> As long this is a conscious and grounded decision, and developers
> understand the relationship between resource and representation (and
> their identities), there is no problem.
>
> This is a relevant W3C document as well - looks like a best practice
> to me: https://www.w3.org/TR/chips/#content
>
> We now went off-list BTW.
>
> On Mon, Feb 29, 2016 at 9:48 PM, Annette Greiner <amgreiner@lbl.gov> wrote:
>> Hi Martynas,
>> Yes, content negotiation is a means of providing alternative representations
>> of a resource. That allows for requests for a response in one of several
>> specific formats. It lets the server automatically choose one representation
>> or another, essentially one file or another. That is different from
>> requesting a document with mixed content, which is what the current BP uses
>> as an example. For embedded RDFa or JSON-LD inserted into HTML, it would
>> just be requested and served as usual (accept text/html), right? No special
>> setup on the server for content negotiation needs to be done to make that
>> work. So, I'm not sure how you would configure content negotiation in this
>> case or what benefit it would be.
>>
>> By API/non-API, I mean to point out the difference in access method. For
>> non-API access, users are obtaining data via the browser and are subject to
>> the limitations of the browser's features. Again, this seems to be what the
>> BP is using as an example, as it refers to serving data in HTML. In the case
>> of retrieving data in this way, it's useful for an individual to have access
>> to both representations. I don't know of a browser that lets me set the
>> "accept" header on the fly as I'm moving from site to site. For APIs, users
>> (developers) get access to the data programmatically, via code they write
>> themselves and therefore can alter to include specific headers (like
>> "accept"). Content negotiation works in that case.
>>
>> But I really see no problem with offering a .json file for a json
>> representation and a .xml for an xml representation of the same resource.
>>  From my own readings and discussions with other developers, I have found
>> that there are multiple schools of thought about how best to serve multiple
>> representations of data from an API. I don't think any of them is a clear
>> "best practice" yet. Even the W3C guidance on serving alternative
>> representations [1], now 10 years old and obviously preceding the trend
>> toward responsive design, acknowledges that there are times when using URIs
>> alone is appropriate. Moreover, I have never heard a claim that content
>> negotiation should be used for serving multiple representations of data
>> within an HTML page or for human browsing of data.
>> -Annette
>>
>>
>>
>> [1] https://www.w3.org/2001/tag/doc/alternatives-discovery.html
>>
>>
>> On 2/27/16 5:31 AM, Martynas Jusevičius wrote:
>>
>> Hey Annette, Not exactly sure what you mean with the API/non-API
>> distinction. I think the only purpose of embedding JSON-LD into HTML is that
>> Google and other search engines decided to index those snippets. In general
>> content negotiation is clearly the recommended way to provide alternative
>> representations. With conneg, Turtle, JSON and other formats are different
>> representations of the same resource. By giving formats their own URIs such
>> as .json, you turn them into standalone resources with a a single
>> representation. Properly implemented HTTP APIs and clients should support
>> conneg and not require URIs for each format. Martynas graphityhq.com
>>
>> On Thu, 25 Feb 2016 at 20:52, Annette Greiner <amgreiner@lbl.gov> wrote:
>>> Hi folks,
>>> I was just looking at the BP about content negotiation.
>>> It says "It is recommended to use content negotiation for serving data
>>> available in multiple formats." It then talks about having structured
>>> data within HTML and serving such pages by using content negotiation. I
>>> have two concerns. First, for a web page with mixed content, I don't
>>> think there is a content type that applies. If you are putting turtle or
>>> json-ld into html, then the content type would still be text/html,
>>> wouldn't it? If the intention is to suggest that people avoid mixing and
>>> instead serve the json in a json representation and the turtle in a
>>> turtle representation, that would work, but unless you are talking about
>>> doing this in an API, it would be really hard for most people to reach
>>> the alternative representations via content negotiation.
>>>
>>> Secondly, even in the context of APIs, I think there is too much
>>> disagreement among web developers to say that using content negotiation
>>> is a clear best practice. You can also specify a representation in the
>>> request URI (foo/file.json, foo/file.ttl), which has the advantage of
>>> enabling sharing through the URI alone.
>>>
>>> I would support a best practice that tells people to move different
>>> non-API representations of data to individual files and serve those
>>> under different URIs.
>>> -Annette
>>>
>>> --
>>> Annette Greiner
>>> NERSC Data and Analytics Services
>>> Lawrence Berkeley National Laboratory
>>>
>>>
>> --
>> Annette Greiner
>> NERSC Data and Analytics Services
>> Lawrence Berkeley National Laboratory
>>

-- 
Annette Greiner
NERSC Data and Analytics Services
Lawrence Berkeley National Laboratory

Received on Tuesday, 1 March 2016 02:33:43 UTC