Re: Replace hydra:Error with application/problem+json

Hi Karol,

actually I didn't consider the fact that it defines a media type and I 
partly agree with you.
 From a REST point of view, it is of course it is best practice to 
define a media-type
and send a "fixed serialization" (JSON in this case).
But for hydra or a semweb driven approach to REST in general,
the problem remains how to integrate it?
Of course we should not seek for a semantic mapping for anything;
so If an API endpoint happens to return application/pdf that's perfectly 
fine.
But for non-payload and API mechanics related information it feels like
a breach for me, to have everything semantically mapped but not errors
(as it would be, if we just decided to use it without further ado as 
Dietrich proposed).

Greets, Thomas

Am 23.09.2015 um 20:32 schrieb Karol Szczepański:
>
> Hi
>
> I’d disagree with you Thomas. While indeed plain JSON is as 
> informative as as a Suahili written text for someone who knows only 
> English, but notice that this spec defines a separate media type which 
> tells client exactly what’s inside and the semantics of what it may 
> receive. Fact that it’s a JSON is somehow redundand, the most 
> important here it’s sub type of ‘problem’, JSON is just a 
> serialization so common clients as browsers can decipher it easily.
>
> This is somehow an issue of Hydra itself that it sticks to RDF so 
> tightly that it sometimes doesn’t fit to what’s actually in the 
> wilderness. ReST with HTTP is bound to media types as HTTP works that 
> way. It also uses status codes, verbs and other protocol specific 
> stuff and I’d like not to change that as we might end up with 
> SOAP-like sanctuary.
>
> But back to the topic – maybe just having a hydra:Error is enough – 
> hydra away client may interprete that when hydra:Error is expected it 
> means client may receive a ‘problem’ in such case? No further 
> description is needed as client will need understand ‘problem’ media type.
>
> Regards
>
> Karol Szczepański
>
>
> *Od: *Thomas Hoppe
> *Wysłano: *środa, 23 września 2015 08:57
> *Do: *public-hydra@w3.org
> *Temat: *Re: Replace hydra:Error with application/problem+json
>
> Hi,
>
> nice idea but in the same way you could argue we should use JSON 
> JSON-Home [1] as API-Documntation (hydra:ApiDocumentation).
> I think we should only have very basic concepts (as Classes) into 
> hydra. With the self-descriptiveness of semantically tagged data,
> you can theoretically use whatever error description format you want 
> -- even multiple at once.
> And this brings me to my critique about those JSON formats that pop-up 
> here and there:
> They don't provide a semantic mapping to an existing vocabulary or 
> introduce a corresponding one.
> So even if we decided to use http-problem, how would we map the 
> classes and properties?
>
> Greets, Thomas
>
> [1] http://tools.ietf.org/html/draft-nottingham-json-home-02
>
> Am 22.09.2015 um 23:00 schrieb Asbjørn Ulsberg:
>
>     Since a soon-to-be-RFC for problems in JSON already exist, I think
>     we should replace hydra:Error with it.
>
>     https://tools.ietf.org/html/draft-ietf-appsawg-http-problem-01
>
>     Opinions?
>
>     -- 
>
>     Asbjørn Ulsberg          -=|=- asbjorn@ulsberg.no
>     <mailto:asbjorn@ulsberg.no>
>
>     «He's a loathsome offensive brute, yet I can't look away»
>