lanthaler
Doesn't open for YourSports test endpoint
Using http://intense-headland-5849.herokuapp.com/giants, the hydra console does not show any results. If you content-negotiate for JSON-LD, you get the following headers:
HTTP/1.1 200 OK
Server: Cowboy
Connection: keep-alive
X-Content-Type-Options: nosniff
Content-Length: 5683
Link: <http://intense-headland-5849.herokuapp.com/api/>; rel="http://www.w3.org/ns/hydra/core#apiDocumentation"
Content-Displosition: inline
Etag: "3544798144723559455"
Vary: Accept, If-None-Match, If-Modified-Since
Content-Type: application/ld+json
Status: 200 OK
Date: Fri, 18 Jul 2014 21:14:30 GMT
Via: 1.1 vegur
You can add .jsonld to avoid using Accept header, which should return the same, except it also sets Location: /giants (should be Location: http://intense-headland-5849.herokuapp.com/giants).
There a couple of issues leading to this behavior. Most importantly, the HydraConsole didn’t set the Accept header correctly which caused the server to return N-Triples. I just fixed this in fc886fd878c47bd47953ac9fcc3ad1e35c49e2aa. Using the /giants.jsonld version doesn’t work because that resource, as you say, returns a Location header which causes a redirect back to /giants which then, again, is returned in N-Triples if the Accept header is missing (as it was before). The simplest thing would be to drop the Location header to make that work. Finally, the modified JSON-LD processor I use to render the response isn’t up to date and thus doesn’t support reverse properties. If that’s fixed, the response should be rendered properly.
There’s a typo in one of the headers: Content-Disp_l_osition. Why did you add that header? Could you please also enable cross-origin access by adding the CORS header Access-Control-Allow-Origin: *
@gkellogg, I’m running into some problems when loading the Hydra ApiDocumentation. The referenced context http://yoursports.com/vocab/ is redirected to https://www.yoursports.com/vocab/ Don’t know why yet, but it can’t be loaded (neither by my processor, nor the json-ld.org playground, nor your distiller). Could you please serve this context directly from herokuapp.com (without https) so that I can check whether the rest works properly now.
Yes, I had rewritten this with other output, just not the API. It should read okay now.
OK, great. The console can’t interpret the API doc as you use features which we discussed but aren’t in the spec yet. Most notably, you point directly to the property in supportedProperty instead of going through an intermediary SupportedProperty. Do you auto-generate the API doc (script/gen_apidoc is empty)? Could we change it for the time being? Also, could you please add hydra:title & hydra:description to each SupportedProperty so that the HydraConsole has something to display.
It is auto-generated, but with script/gen_vocab. (The other was for generating HTML API documentation, but just a place-holder.
Changing the way supportedProperties works would likely break the application, but I can look into it. That's why I've been trying to drive closure on these features.
I can certainly ensure that title/description exist.
Changing the way supportedProperties works would likely break the application, but I can look into it. That's why I've been trying to drive closure on these features.
Does your app consume the HTTP Link header? If not, we could simply generate a separate file for the time being. I have to re-read the discussions regarding Hydra ISSUE-37. I'll try to get out a call for consensus (or at least some new discussions) shortly.
It generates the Link header, but doesn't consume it. It's not a Hydra client, but a server, so there's not much point in consuming.
There are, of course, other features you probably don't yet implement, such as hydra:collection, but I can see about reverting the work on supportedProperty/PropertyConstraint.
It generates the Link header, but doesn't consume it. It's not a Hydra client, but a server, so there's not much point in consuming.
That's what I thought. So it shouldn't be a problem to simply generate a second version of the Hydra ApiDocumentation and point to that one in the Link header. Nothing would break but the HydraConsole would get what it needs. It also means that we can directly compare the two approaches... which might help to decide which one to use in the end.
I pushed a new version of the HydraConsole last night. It renders responses correctly now. As soon as the ApiDocumentation is served according to the current spec, the console should also be able to retrieve and render it.
Okay, finally got the demonstrator updated with documentation. They both pull down using Ajax now.
API doesn't seem to show any operations, and has some odd spacing issues.
Regarding the special treatment for the "ys" prefix (see application.js#L17 and application.js#L134), that's there so that a URI of http://yoursports.com/vocab/RegisteredUser, will resolve appropriately. Anything from another vocabulary will look like http://yoursports.com/vocab/schema:Person. This is at odds with having @vocab set to schema.org, so we might want to consider changing (or just removing) that.