Print

Print


You are absolutely correct.  The correct negotiation request would be: application/ld+json, application/json;q=0.9

That says, I want JSONLD, but will accept any JSON.  I *don't* get to just pick another JSON format if they asked only for ld+json.  But, given the recordAccept (yes, I just coined that name now) parameter above, I *would* be allowed to return application/vnd.oclc.viaf+json if I wasn't able to return application/ld+json.

Ralph

-----Original Message-----
From: SRU (Search and Retrieve Via URL) Implementors [mailto:[log in to unmask]] On Behalf Of Jonathan Rochkind
Sent: Wednesday, February 19, 2014 4:44 PM
To: [log in to unmask]
Subject: Re: SRU recordPacking and JSON

I'm wondering whether it actually makes sense at all to content negotiate to a different JSON-based format then the one you think they are asking for?

Does someone have a use case where software asking for one JSON-based format, but which gets a different JSON-based format instead, is still going to be able to do something useful with it? It's not something I've encountered myself.

Even for "+xml" content types (which actually are standardized -- every content type ending in "+xml" must, by standard, be an XML type; the same is not true of "+json") -- I don't _think_ conneg usually works such that a client asking for only "something+xml" is given "other+xml" 
instead -- rather than an error message saying "something+xml" can not be provided.


On 2/19/14 4:13 PM, LeVan,Ralph wrote:
>>  Sure, it's just as sensible, the concept is good. But how you go 
>> about
> doing content
>
>>negotiation at the record level?  Can you give an example.
>
> http://rdap02pxdu.dev.oclc.org:8080/viaf/search?query=local.names+all+
> %22ralph%20levan%22&httpAccept=application/json
>
> Here's a generic request for an SRU response in JSON.  It doesn't say 
> anything about how the records should be returned, but certainly 
> implies that they should be in JSON too.  (Sadly, it gets an XML 
> record now, because I'm not doing record content negotiation yet.)  
> Right now, I have two different JSON schemas: vnd.oclc.viaf+json 
> (that's my VIAF XML record run through a lovely mechanical XML->JSON 
> translator) and ld+json (that's a hand-built implementation of the 
> current Linked Data in JSON proposal).  I'd propose specifying them 
> using recordSchema (that being the closest match we have.)
>
> http://rdap02pxdu.dev.oclc.org:8080/viaf/search?query=local.names+all+
> %22ralph%20levan%22&httpAccept=application/json&recordSchema=applicati
> on/ld%2Bjson(Sadly, that URL gets you a nice SRU diagnostic returned 
> as JSON, because that recordSchema isn't recognized yet.  I'm really 
> hoping for some feedback on the idea before I implement record content 
> negotiation.)
>
> Now, if they asked for application/bob+json, then we fall into regular 
> HTTP negotiation and I'd return what I thought was my best JSON and 
> I'd tell them they were getting application/vnd.oclc.viaf+json in the 
> recordSchema element (or whatever they get called in JSON) of the 
> record response.
>
> Ralph
>
> p.s. Here's the hack I'm using right now to get that VIAF record in 
> JSON.  Like I said, I'm looking for a cleaner way to do this that 
> doesn't make you all gag. J
>
> http://rdap02pxdu.dev.oclc.org:8080/viaf/search?query=local.names+all+
> %22ralph%20levan%22&recordPacking=string&recordSchema=JSON&httpAccept=application/json
>